Modifications à venir des cookies SameSite dans ASP.NET et ASP.NET Core

SameSite est une extension de 2016 des cookies HTTP destinée à atténuer la falsification de demandes intersites (CSRF). La conception originale était une fonctionnalité opt-in qui pouvait être utilisée en ajoutant une nouvelle propriété SameSite aux cookies. Il avait deux valeurs, Lax et Strict.

La définition de la valeur à Lax indique que le cookie doit être envoyé lors de la navigation au sein du même site, ou via la navigation GET sur votre site à partir d'autres sites. Une valeur de Strict a limité le cookie aux demandes qui provenaient uniquement du même site. Le fait de ne pas définir la propriété du tout n'a placé aucune restriction sur la façon dont le cookie a circulé dans les demandes. Les opérations d'authentification OpenIdConnect (par exemple, connexion, déconnexion) et d'autres fonctionnalités qui envoient des requêtes POST d'un site externe au site demandant l'opération, peuvent utiliser des cookies pour la corrélation et / ou la protection CSRF. Ces opérations devraient se retirer de SameSite, en ne définissant pas du tout la propriété, pour garantir que ces cookies seront envoyés lors de leurs flux de demandes spécialisées.

Google met à jour la norme et implémente les modifications proposées dans une prochaine version de Chrome. La modification ajoute une nouvelle valeur SameSite, "Aucun" et change le comportement par défaut en "Lax". Cela interrompt les connexions OpenIdConnect, et potentiellement d'autres fonctionnalités sur lesquelles votre site Web peut s'appuyer, ces fonctionnalités devront utiliser des cookies dont la propriété SameSite est définie sur une valeur "Aucune".

Cependant, les navigateurs qui adhèrent à la norme d'origine et ne connaissent pas la nouvelle valeur ont un comportement différent de celui des navigateurs qui utilisent la nouvelle norme comme norme SameSite. Si un navigateur voit une valeur pour SameSite, il ne comprend pas qu'il devrait traiter cette valeur comme "Strict." Cela signifie que votre site Web .NET devra maintenant ajouter un reniflement d'agent utilisateur pour décider si vous envoyez la nouvelle valeur None ou si vous n'envoyez pas l'attribut du tout.



.NET publiera des mises à jour pour modifier le comportement de son attribut SameSite dans .NET 4.7.2 et .NET Core 2.1 et versions ultérieures afin de refléter l'introduction par Google d'une nouvelle valeur. Les mises à jour pour .NET Framework seront disponibles le 19 novembre en tant que mise à jour facultative via Microsoft Update et WSUS si vous utilisez la fonctionnalité "Rechercher les mises à jour". Le 10 décembre, il deviendra largement disponible et apparaîtra dans Microsoft Update sans que vous ayez à vérifier spécifiquement les mises à jour. Les mises à jour de .NET Core seront disponibles avec .NET Core 3.1 à partir de l'aperçu 1, en novembre.

.NET Core 3.1 contiendra une définition d'énumération mise à jour , SameSite.Unspecified qui ne définira pas la propriété SameSite.

Le middleware OpenIdConnect pour Microsoft.Owin v4.1 et .NET Core sera mis à jour en même temps que leurs mises à jour .NET Framework et .NET, mais nous ne pouvons pas introduire le code de reniflement de l'agent utilisateur dans le framework, cela doit être implémenté dans votre code du site. L'implémentation de l'agent sniffing variera en fonction de la version d'ASP.NET ou d'ASP.NET Core que vous utilisez et des navigateurs que vous souhaitez prendre en charge.

Pour ASP.NET 4.7.2 avec Microsoft.Owin 4.1.0, le reniflage d'agent peut être implémenté à l'aide de ICookieManager ;

public class SameSiteCookieManager : ICookieManager { private readonly ICookieManager _innerManager; public SameSiteCookieManager() : this(new CookieManager()) { } public SameSiteCookieManager(ICookieManager innerManager) { _innerManager = innerManager; } public void AppendResponseCookie(IOwinContext context, string key, string value, CookieOptions options) { CheckSameSite(context, options); _innerManager.AppendResponseCookie(context, key, value, options); } public void DeleteCookie(IOwinContext context, string key, CookieOptions options) { CheckSameSite(context, options); _innerManager.DeleteCookie(context, key, options); } public string GetRequestCookie(IOwinContext context, string key) { return _innerManager.GetRequestCookie(context, key); } private void CheckSameSite(IOwinContext context, CookieOptions options) { if (DisallowsSameSiteNone(context) && options.SameSite == SameSiteMode.None) { options.SameSite = null; } } public static bool DisallowsSameSiteNone(IOwinContext context) { // TODO: Use your User Agent library of choice here. var userAgent = context.Request.Headers["User-Agent"]; return userAgent.Contains("BrokenUserAgent") || userAgent.Contains("BrokenUserAgent2") } } 

Et puis configurez les paramètres OpenIdConnect pour utiliser le nouveau CookieManager;

 app.UseOpenIdConnectAuthentication( new OpenIdConnectAuthenticationOptions { // … Your preexisting options … CookieManager = new SameSiteCookieManager(new SystemWebCookieManager()) }); 

SystemWebCookieManager aura besoin du correctif SameSite .NET 4.7.2 ou version ultérieure installé pour fonctionner correctement.

Pour ASP.NET Core, vous devez installer les correctifs, puis implémenter le code de détection d'agent dans une politique de cookies . Pour les versions antérieures à 3.1, remplacez SameSiteMode.Unspecified par (SameSiteMode) (- 1).

 private void CheckSameSite(HttpContext httpContext, CookieOptions options) { if (options.SameSite > SameSiteMode.Unspecified) { var userAgent = httpContext.Request.Headers["User-Agent"].ToString(); // TODO: Use your User Agent library of choice here. if (/* UserAgent doesn't support new behavior */) { // For .NET Core < 3.1 set SameSite = -1 options.SameSite = SameSiteMode.Unspecified; } } } public void ConfigureServices(IServiceCollection services) { services.Configure<CookiePolicyOptions>(options => { options.MinimumSameSitePolicy = SameSiteMode.Unspecified; options.OnAppendCookie = cookieContext => CheckSameSite(cookieContext.Context, cookieContext.CookieOptions); options.OnDeleteCookie = cookieContext => CheckSameSite(cookieContext.Context, cookieContext.CookieOptions); }); } public void Configure(IApplicationBuilder app) { app.UseCookiePolicy(); // Before UseAuthentication or anything else that writes cookies. app.UseAuthentication(); // … } 

Lors de tests avec l'équipe Azure Active Directory, nous avons constaté que les vérifications suivantes fonctionnent pour tous les agents utilisateurs courants qu'Azure Active Directory voit qui ne comprennent pas la nouvelle valeur.

 public static bool DisallowsSameSiteNone(string userAgent) {    // Cover all iOS based browsers here. This includes:    // - Safari on iOS 12 for iPhone, iPod Touch, iPad    // - WkWebview on iOS 12 for iPhone, iPod Touch, iPad    // - Chrome on iOS 12 for iPhone, iPod Touch, iPad    // All of which are broken by SameSite=None, because they use the iOS networking stack    if (userAgent.Contains("CPU iPhone OS 12") || userAgent.Contains("iPad; CPU OS 12"))    {        return true;    }    // Cover Mac OS X based browsers that use the Mac OS networking stack. This includes:    // - Safari on Mac OS X.    // This does not include:    // - Chrome on Mac OS X    // Because they do not use the Mac OS networking stack.    if (userAgent.Contains("Macintosh; Intel Mac OS X 10_14") && userAgent.Contains("Version/") && userAgent.Contains("Safari"))    {        return true;    }    // Cover Chrome 50-69, because some versions are broken by SameSite=None, // and none in this range require it.    // Note: this covers some pre-Chromium Edge versions, // but pre-Chromium Edge does not require SameSite=None.    if (userAgent.Contains("Chrome/5") || userAgent.Contains("Chrome/6"))    {        return true;    }    return false; } 

Cette liste de navigateurs n'est en aucun cas canonique et vous devez valider que les navigateurs courants et autres agents utilisateurs pris en charge par votre système se comportent comme prévu une fois la mise à jour en place.

Chrome 80 devrait activer le nouveau comportement en février ou mars 2020, y compris une atténuation temporaire ajoutée dans Chrome 79 Beta. Si vous souhaitez tester le nouveau comportement sans atténuation, utilisez Chromium 76. Les anciennes versions de Chromium sont disponibles en téléchargement .

Si vous ne pouvez pas mettre à jour vos versions de framework au moment où Chrome transforme le nouveau comportement au début de 2020, vous pourrez peut-être changer votre flux OpenIdConnect en un flux de code, plutôt que le flux implicite par défaut qu'ASP.NET et ASP.NET Core utilise, mais cela devrait être considéré comme une mesure temporaire.


Nous vous encourageons vivement à télécharger les versions mises à jour de .NET Framework et .NET Core lorsqu'elles seront disponibles en novembre et de commencer à planifier votre mise à jour avant le déploiement des modifications de Chrome.

Source: https://habr.com/ru/post/fr473142/


All Articles