Trabajar con cookies de SameSite en ASP.NET

Por Rick Anderson

SameSite es un estándar de borrador de IETF diseñado para proporcionar cierta protección contra ataques de falsificación de solicitud entre sitios (CSRF). Redactado originalmente en 2016, el borrador del estándar se actualizó en 2019. El estándar actualizado no es compatible con el estándar anterior, siendo las diferencias más notables:

  • Las cookies sin encabezado de SameSite se tratan como SameSite=Lax de manera predeterminada.
  • SameSite=None debe usarse para permitir el uso de cookies entre sitios.
  • Las cookies que declaran SameSite=None también deben marcarse como Secure.
  • Las aplicaciones que usan <iframe> pueden experimentar problemas con las cookies de sameSite=Lax o sameSite=Strict porque <iframe> se trata como escenario entre sitios.
  • El valor SameSite=None no está permitido por el estándar de 2016 y hace que algunas implementaciones traten esas cookies como SameSite=Strict. Consulte Compatibilidad con exploradores más antiguos en este documento.

La configuración de SameSite=Lax funciona para la mayoría de las cookies de aplicaciones. Algunas formas de autenticación como OpenID Connect (OIDC) y WS-Federation usan de manera predeterminada redireccionamientos basados en POST. Las redirecciones basadas en POST desencadenan las protecciones del explorador de SameSite, por lo que SameSite está deshabilitado para estos componentes. La mayoría de los inicios de sesión de OAuth no se ven afectados debido a las diferencias en la forma en que fluye la solicitud.

Cada componente ASP.NET que emite cookies debe decidir si SameSite es adecuado.

Consulte Problemas conocidos de problemas con las aplicaciones después de instalar las actualizaciones de .Net SameSite de 2019.

Uso de SameSite en ASP.NET 4.7.2 y 4.8

.Net 4.7.2 y 4.8 admite el estándar de borrador de 2019 para SameSite desde la publicación de actualizaciones en diciembre de 2019. Los desarrolladores pueden controlar mediante programación el valor del encabezado SameSite mediante la propiedad HttpCookie.SameSite. Al establecer la propiedad SameSite en Strict, Lax o None, esos valores se escriben en la red junto con la cookie. Si se establece en igual a (SameSiteMode)(-1) , se indica que no se debe incluir ningún encabezado SameSite en la red con la cookie. La propiedad HttpCookie.Secure, o "requireSSL" en los archivos de configuración, se puede usar para marcar la cookie como Secure o no.

Las nuevas HttpCookie instancias tendrán como valor predeterminado SameSite=(SameSiteMode)(-1) y Secure=false. Estos valores predeterminados se pueden sobrescribir en la system.web/httpCookies sección de configuración, donde la cadena "Unspecified" es una sintaxis sencilla solo de configuración para (SameSiteMode)(-1):

<configuration>
 <system.web>
  <httpCookies sameSite="[Strict|Lax|None|Unspecified]" requireSSL="[true|false]" />
 <system.web>
<configuration>

ASP.Net también emite cuatro cookies específicas propias para estas características: Autenticación anónima, Autenticación de formularios, Estado de sesión y Administración de roles. Las instancias de estas cookies obtenidas en tiempo de ejecución se pueden manipular mediante las SameSite propiedades y Secure como cualquier otra instancia de HttpCookie. Sin embargo, debido al desarrollo fragmentado del estándar SameSite, las opciones de configuración de estas cuatro características de las cookies son inconsistentes. A continuación se muestran las secciones y atributos de configuración pertinentes, con valores predeterminados. Si no hay ningún atributo relacionado SameSite o Secure para una característica, la característica recurrirá a los valores predeterminados configurados en la sección system.web/httpCookies descrita anteriormente.

<configuration>
 <system.web>
  <anonymousIdentification cookieRequireSSL="false" /> <!-- No config attribute for SameSite -->
  <authentication>
   <forms cookieSameSite="Lax" requireSSL="false" />
  </authentication>
  <sessionState cookieSameSite="Lax" /> <!-- No config attribute for Secure -->
  <roleManager cookieRequireSSL="false" /> <!-- No config attribute for SameSite -->
 <system.web>
<configuration>

Nota: "Sin especificar" solo está disponible para system.web/httpCookies@sameSite en este momento. Esperamos agregar una sintaxis similar a los atributos cookieSameSite mostrados anteriormente en futuras actualizaciones. La configuración (SameSiteMode)(-1) en el código sigue funcionando en instancias de estas cookies.*

Si está leyendo esto en un idioma distinto del inglés, háganoslo saber en este problema de discusión de GitHub si desea ver los comentarios de código en su idioma nativo.

Redestinar aplicaciones .NET

Para tener como destino .NET 4.7.2 o posterior:

  • Asegúrese de queweb.config contiene lo siguiente: 

    <system.web>
  <compilation targetFramework="4.7.2"/>
  <httpRuntime targetFramework="4.7.2"/>
</system.web>

  • Compruebe que el archivo del proyecto contiene la versión correcta de TargetFrameworkVersion:

    <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>

    La Guía de migración de .NET tiene más detalles.

  • Compruebe que los paquetes NuGet del proyecto están dirigidos a la versión correcta del marco. Puede comprobar la versión correcta del marco examinando el archivo packages.config , por ejemplo:

    <?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Microsoft.AspNet.Mvc" version="5.2.7" targetFramework="net472" />
  <package id="Microsoft.ApplicationInsights" version="2.4.0" targetFramework="net451" />
</packages>

    En el archivo anterior packages.config, el paquete Microsoft.ApplicationInsights:

    • Está dirigido a .NET 4.5.1.
    • Debe actualizar su atributo targetFramework a net472 si existe un paquete actualizado destinado a su marco de trabajo.

Versiones de .NET anteriores a la 4.7.2

Microsoft no admite versiones de .NET inferiores a la 4.7.2 para escribir el mismo atributo de cookie de sitio. No hemos encontrado una manera confiable de:

  • Asegúrese de que el atributo está escrito correctamente en función de la versión del explorador.
  • Intercepte y ajuste las cookies de autenticación y sesión en versiones anteriores del marco de trabajo.

Cambios de comportamiento del parche de diciembre

El cambio de comportamiento específico para .NET Framework es cómo la propiedad SameSite interpreta el valor None.

  • Antes del parche, un valor de None significaba:
    • No emita el atributo en absoluto.
  • Después del parche.
    • Un valor de None significa "Emitir el atributo con un valor de None".
    • Un SameSite valor de (SameSiteMode)(-1) hace que el atributo no se emita.

El valor predeterminado de SameSite para la autenticación de formularios y las cookies de estado de sesión se cambiaron de None a Lax.

Resumen del impacto en los cambios en los exploradores

Si instala el parche y emite una cookie con SameSite.None, se dará una de las siguientes situaciones:

  • Chrome v80 tratará esta cookie según la nueva implementación y no aplicará las mismas restricciones de sitio en la cookie.
  • Cualquier explorador que no se haya actualizado para admitir la nueva implementación seguirá la implementación anterior. La implementación anterior dice:
    • Si ve un valor que no entiende, ignórelo y cambie a restricciones estrictas de mismo sitio.

Por lo tanto, la aplicación falla en Chrome o falla en numerosos otros contextos.

Historial y cambios

La compatibilidad con SameSite se implementó por primera vez en .NET 4.7.2 con el estándar de borrador de 2016.

Las actualizaciones del 19 de noviembre de 2019 para Windows actualizaron .NET 4.7.2+ desde el estándar 2016 hasta el estándar 2019. Próximamente se publicarán actualizaciones adicionales para otras versiones de Windows. Para obtener más información, vea artículos de KB que admiten SameSite en .NET Framework.

El borrador de 2019 de la especificación SameSite:

  • No es retrocompatible con el borrador de 2016. Para más información, vea Compatibilidad con exploradores más antiguos en este documento.
  • especifica que las cookies se tratan como SameSite=Lax de manera predeterminada;
  • Especifica las cookies que declaran SameSite=None explícitamente para habilitar la entrega entre sitios también deben marcarse como Secure.
  • Es compatible con los parches emitidos según se describe en los KB enumerados anteriormente.
  • Está previsto que Chrome lo habilite de manera predeterminada en febrero de 2020. Los exploradores empezaron a pasar a este estándar en 2019.

Problemas conocidos

Dado que las especificaciones del borrador de 2016 y 2019 no son compatibles, la actualización de .Net Framework de noviembre de 2019 introduce algunos cambios que pueden ser disruptivos.

  • Las cookies de autenticación de formularios y estado de sesión ahora se escriben en la red como Lax en lugar de no especificadas.
    • Aunque la mayoría de las aplicaciones funcionan con SameSite=Lax cookies, las aplicaciones que realizan POST en sitios o aplicaciones que utilizan iframe pueden encontrar que sus cookies de autorización de formularios o de estado de sesión no se están utilizando como se esperaba. Para solucionar este problema, cambie el cookieSameSite valor de la sección de configuración adecuada como se ha descrito anteriormente.
  • HttpCookies que se establecen SameSite=None explícitamente en el código o la configuración ahora tienen ese valor escrito con la cookie, mientras que anteriormente se omitía. Esto puede causar problemas con exploradores anteriores que solo admiten el estándar de borrador de 2016.
    • Al dirigirse a navegadores que admiten el borrador de estándar de 2019 con SameSite=None cookies, recuerde también marcarlas Secure o es posible que no se reconozcan.
    • Para revertir al comportamiento de 2016 de no escribir SameSite=None, use la configuración aspnet:SupressSameSiteNone=truede la aplicación . Tenga en cuenta que esto se aplicará a todos los HttpCookies de la aplicación.

Consulte Azure App Service: Administración de cookies de SameSite y revisión de .NET Framework 4.7.2 para obtener información sobre cómo Azure App Service configura comportamientos de SameSite en aplicaciones de .Net 4.7.2.

Compatibilidad con exploradores más antiguos

El estándar de SameSite de 2016 obligaba a tratar los valores desconocidos como valores de SameSite=Strict. Las aplicaciones a las que se accede desde exploradores antiguos que admiten el estándar de SameSite de 2016 pueden interrumpirse cuando obtienen una propiedad de SameSite con un valor de None. Las aplicaciones web deben implementar la detección de navegadores si pretenden ser compatibles con navegadores antiguos. ASP.NET no implementa la detección del explorador porque los valores de User-Agents son muy volátiles y cambian con frecuencia.

El enfoque de Microsoft para solucionar el problema es ayudarle a implementar componentes de detección de exploradores para quitar el sameSite=None atributo de las cookies si se sabe que un explorador no lo admite. El consejo de Google era emitir cookies dobles, una con el nuevo atributo y otra sin el atributo en absoluto. Sin embargo, consideramos que los consejos de Google están limitados. Algunos exploradores, especialmente los navegadores móviles tienen límites muy pequeños en el número de cookies que un sitio o un nombre de dominio pueden enviar. El envío de varias cookies, especialmente cookies de gran tamaño, como las cookies de autenticación, puede alcanzar el límite del navegador móvil muy rápidamente, lo que provoca errores en la aplicación que son difíciles de diagnosticar y corregir. Además, como marco hay un gran ecosistema de código y componentes de terceros que pueden no actualizarse para usar un enfoque de doble cookie.

El código de detección del explorador usado en los proyectos de ejemplo de este repositorio de GitHub se encuentra en dos archivos.

Estas detecciones son los agentes de explorador más comunes que hemos visto que son compatibles con el estándar de 2016 y para los que el atributo debe quitarse completamente. No está pensado como una implementación completa:

  • Es posible que tu aplicación detecte navegadores que nuestros sitios de prueba no ven.
  • Debe estar preparado para agregar detecciones según sea necesario para su entorno.

La forma de conectar la detección varía según la versión de .NET y el marco web que usa. Se puede llamar al código siguiente en el sitio de llamada httpCookie :

private void CheckSameSite(HttpContext httpContext, HttpCookie cookie)
{
    if (cookie.SameSite == SameSiteMode.None)
    {
        var userAgent = httpContext.Request.UserAgent;
        if (BrowserDetection.DisallowsSameSiteNone(userAgent))
        {
            cookie.SameSite = (SameSiteMode)(-1);
        }
    }
}

Consulte los siguientes temas de cookies ASP.NET 4.7.2 SameSite:

Asegurarse de que el sitio redirige a HTTPS

Para ASP.NET 4.x, WebForms y MVC, se puede usar la característica reescritura de direcciones URL de IIS para redirigir todas las solicitudes a HTTPS. El siguiente XML muestra una regla de ejemplo:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Redirect to https" stopProcessing="true">
          <match url="(.*)"/>
          <conditions>
            <add input="{HTTPS}" pattern="Off"/>
            <add input="{REQUEST_METHOD}" pattern="^get$|^head$" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent"/>
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

En las instalaciones locales de IIS URL Rewrite es una característica opcional que puede necesitar la instalación.

Probar aplicaciones para problemas de SameSite

Debes probar tu aplicación con los exploradores que admitas y pasar por tus escenarios que implican cookies. Los escenarios de cookies suelen implicar

  • Formularios de inicio de sesión
  • Mecanismos de inicio de sesión externos, como Facebook, Azure AD, OAuth y OIDC
  • Páginas que aceptan solicitudes de otros sitios
  • Páginas de la aplicación diseñadas para insertarse en iframes

Debes comprobar que las cookies se crean, conservan y eliminan correctamente en tu aplicación.

Las aplicaciones que interactúan con sitios remotos, por ejemplo mediante inicio de sesión de terceros, necesitan:

Probar las aplicaciones web usando una versión cliente que pueda incorporarse al nuevo comportamiento de SameSite. Chrome, Firefox y Chromium Edge tienen nuevas banderas de funciones opcionales que se pueden usar para pruebas. Una vez que la aplicación aplique las revisiones de SameSite, pruébela con versiones de cliente anteriores, especialmente Safari. Para más información, vea Compatibilidad con exploradores más antiguos en este documento.

Prueba con Chrome

Chrome 78+ proporciona resultados engañosos porque tiene una mitigación temporal en su lugar. La mitigación temporal de Chrome 78+ admite cookies de menos de dos minutos de antigüedad. Chrome 76 o 77 con las marcas de prueba adecuadas habilitadas proporciona resultados más precisos. Para probar el nuevo comportamiento SameSite, cambie chrome://flags/#same-site-by-default-cookies a Habilitado. Se ha informado de que las versiones más antiguas de Chrome (75 e inferiores) fallan con la nueva configuración de None. Consulte Compatibilidad con exploradores más antiguos en este documento.

Google no hace que las versiones de Chrome anteriores estén disponibles. Siga las instrucciones que aparecen en Descargar Chromium para probar versiones anteriores de Chrome. No descargue Chrome desde los vínculos proporcionados mediante la búsqueda de versiones anteriores de Chrome.

A partir de la versión de Canary 80.0.3975.0, la mitigación temporal Lax+POST se puede deshabilitar con fines de prueba con la nueva marca --enable-features=SameSiteDefaultChecksMethodRigorously para permitir la prueba de sitios y servicios en el estado final de la característica en la que se ha quitado la mitigación. Para más información, consulte las Actualizaciones de SameSite de The Chromium Projects

Prueba con Chrome 80+

Descargue una versión de Chrome que admita su nuevo atributo. En el momento de escribir, la versión actual es Chrome 80. Chrome 80 necesita la marca chrome://flags/#same-site-by-default-cookies habilitada para usar el nuevo comportamiento. También debe habilitar (chrome://flags/#cookies-without-same-site-must-be-secure) para probar el comportamiento futuro de las cookies que no tienen habilitado el atributo SameSite. Chrome 80 está programado para realizar el cambio para tratar las cookies sin el atributo como SameSite=Lax, aunque con un período de gracia cronometrado para determinadas solicitudes. Para deshabilitar el período de gracia temporizada, el Chrome 80 se puede iniciar con el siguiente argumento de línea de comandos:

--enable-features=SameSiteDefaultChecksMethodRigorously

Chrome 80 tiene mensajes de advertencia en la consola del navegador sobre la falta de atributos sameSite. Use F12 para abrir la consola del explorador.

Prueba con Safari

Safari 12 implementó estrictamente el borrador anterior y produce un error cuando el nuevo None valor está en una cookie. None se evita a través del código de detección del explorador Compatibilidad con exploradores más antiguos en este documento. Pruebe los inicios de sesión con estilo del sistema operativo basados en Safari 12, Safari 13 y WebKit, usando MSAL, ADAL o cualquier biblioteca que esté utilizando. El problema depende de la versión del sistema operativo subyacente. Se sabe que OSX Mojave (10.14) e iOS 12 tienen problemas de compatibilidad con el nuevo comportamiento de SameSite. Actualizar el sistema operativo a OSX Catalina (10.15) o iOS 13 soluciona el problema. Safari no tiene por el momento una bandera de selección para probar el comportamiento de la nueva especificación.

Prueba con Firefox

La compatibilidad de Firefox con el nuevo estándar puede probarse en la versión 68+ accediendo a la página about:config con la marca de características network.cookie.sameSite.laxByDefault. No ha habido informes de problemas de compatibilidad con versiones anteriores de Firefox.

Prueba con el navegador Edge (heredado)

Edge admite el antiguo estándar de SameSite. La versión 44+ de Edge no tiene problemas de compatibilidad conocidos con el nuevo estándar.

Prueba con Edge (Chromium)

Los indicadores de SameSite se establecen en la página de edge://flags/#same-site-by-default-cookies. No se detectaron problemas de compatibilidad con Edge Chromium.

Prueba con Electron

Las versiones de Electron incluyen versiones anteriores de Chromium. Por ejemplo, la versión de Electron usada por Teams es Chromium 66, que muestra el comportamiento anterior. Debe realizar sus propias pruebas de compatibilidad con la versión de Electron que usa el producto. Consulte Compatibilidad con exploradores más antiguos.

Revertir revisiones de SameSite

Puede revertir el comportamiento actualizado de sameSite en las aplicaciones de .NET Framework a su comportamiento anterior, donde el atributo sameSite no se emite para un valor de None, y revertir las cookies de autenticación y sesión para no emitir el valor. Esto debe verse como una corrección extremadamente temporal, ya que los cambios de Chrome interrumpirán las solicitudes POST externas o la autenticación para los usuarios que usan exploradores que admiten los cambios en el estándar.

Revertir el comportamiento de .NET 4.7.2

Actualice web.config para incluir las siguientes opciones de configuración:

<configuration> 
  <appSettings>
    <add key="aspnet:SuppressSameSiteNone" value="true" />
  </appSettings>
 
  <system.web> 
    <authentication> 
      <forms cookieSameSite="None" /> 
    </authentication> 
    <sessionState cookieSameSite="None" /> 
  </system.web> 
</configuration>

Recursos adicionales

  • Last updated on