Próximos cambios de cookies de SameSite en ASP.NET y ASP.NET Core

SameSite es una extensión de 2016 para cookies HTTP destinada a mitigar la falsificación de solicitudes entre sitios (CSRF). El diseño original era una función opcional que se podía usar agregando una nueva propiedad SameSite a las cookies. Tenía dos valores, Lax y Strict.

Al establecer el valor en Lax, se indica que la cookie se debe enviar en la navegación dentro del mismo sitio o mediante la navegación GET a su sitio desde otros sitios. Un valor de Strict limitó la cookie a solicitudes que solo se originaron en el mismo sitio. No establecer la propiedad en absoluto no impuso restricciones sobre cómo fluía la cookie en las solicitudes. Las operaciones de autenticación de OpenIdConnect (por ejemplo, inicio de sesión, cierre de sesión) y otras características que envían solicitudes POST desde un sitio externo al sitio que solicita la operación, pueden usar cookies para la correlación y / o protección CSRF. Estas operaciones tendrían que darse de baja de SameSite, al no establecer la propiedad en absoluto, para garantizar que estas cookies se enviarán durante sus flujos de solicitudes especializadas.

Google ahora está actualizando el estándar e implementando los cambios propuestos en una próxima versión de Chrome. El cambio agrega un nuevo valor de SameSite, "Ninguno", y cambia el comportamiento predeterminado a "Lax". Esto interrumpe los inicios de sesión de OpenIdConnect y, potencialmente, otras características en las que su sitio web puede confiar, estas características tendrán que usar cookies cuya propiedad SameSite se establece en un valor de "Ninguno".

Sin embargo, los navegadores que se adhieren al estándar original y desconocen el nuevo valor tienen un comportamiento diferente al de los navegadores que usan el nuevo estándar ya que el estándar SameSite establece que si un navegador ve un valor para SameSite, no entiende que debe tratar ese valor como "Estricto". Esto significa que su sitio web .NET ahora tendrá que agregar el rastreo de agente de usuario para decidir si envía el nuevo valor None o no envía el atributo.



.NET emitirá actualizaciones para cambiar el comportamiento de su atributo SameSite en .NET 4.7.2 y en .NET Core 2.1 y superior para reflejar la introducción de Google de un nuevo valor. Las actualizaciones para .NET Framework estarán disponibles el 19 de noviembre como una actualización opcional a través de Microsoft Update y WSUS si usa la funcionalidad "Buscar actualizaciones". El 10 de diciembre estará ampliamente disponible y aparecerá en Microsoft Update sin que tenga que buscar específicamente actualizaciones. Las actualizaciones de .NET Core estarán disponibles con .NET Core 3.1 a partir de la vista previa 1, en noviembre.

.NET Core 3.1 contendrá una definición de enumeración actualizada , SameSite.Unspecified que no establecerá la propiedad SameSite.

El middleware OpenIdConnect para Microsoft.Owin v4.1 y .NET Core se actualizará al mismo tiempo que sus actualizaciones de .NET Framework y .NET, sin embargo, no podemos introducir el código de rastreo del agente de usuario en el marco, esto debe implementarse en su código del sitio La implementación del rastreo de agentes variará según la versión de ASP.NET o ASP.NET Core que esté utilizando y los navegadores que desee admitir.

Para ASP.NET 4.7.2 con Microsoft.Owin 4.1.0 se puede implementar la detección de agentes mediante 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") } } 

Y luego configure los ajustes de OpenIdConnect para usar el nuevo CookieManager;

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

SystemWebCookieManager necesitará el .NET 4.7.2 o posterior parche SameSite instalado para funcionar correctamente.

Para ASP.NET Core, debe instalar los parches y luego implementar el código de rastreo del agente dentro de una política de cookies . Para versiones anteriores a 3.1, reemplace SameSiteMode.Unspecified con (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(); // … } 

Al realizar pruebas con el equipo de Azure Active Directory, hemos encontrado que las siguientes comprobaciones funcionan para todos los agentes de usuario comunes que Azure Active Directory ve que no comprenden el nuevo valor.

 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; } 

Esta lista de navegadores no es en absoluto canónica y debe validar que los navegadores comunes y otros agentes de usuario que admite su sistema se comporten como se espera una vez que la actualización esté en su lugar.

Chrome 80 está programado para activar el nuevo comportamiento en febrero o marzo de 2020, incluida una mitigación temporal agregada en Chrome 79 Beta. Si desea probar el nuevo comportamiento sin la mitigación, use Chromium 76. Las versiones anteriores de Chromium están disponibles para descargar .

Si no puede actualizar sus versiones de marco para cuando Chrome cambie el nuevo comportamiento a principios de 2020, puede cambiar su flujo OpenIdConnect a un flujo de Código, en lugar del flujo implícito predeterminado que ASP.NET y ASP.NET Core usan, pero Esto debe ser visto como una medida temporal.


Le recomendamos encarecidamente que descargue las versiones actualizadas de .NET Framework y .NET Core cuando estén disponibles en noviembre y comience a planificar su actualización antes de que se implementen los cambios de Chrome.

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


All Articles