Compartir a través de

Trabajo con cookies de SameSite en ASP.NET

  • Artículo

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 se debe usar para permitir el uso de las 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 de 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.

Usar 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 el lanzamiento de actualizaciones en diciembre de 2019. Los desarrolladores pueden controlar mediante programación el valor del mismo encabezado de SameSite mediante la propiedad HttpCookie.SameSite. Si establece la propiedad SameSite en Strict, Lax o None, esos valores se escribirán en la red con la cookie. Si se establece en igual a (SameSiteMode)(-1), se indica que no se debe incluir ningún encabezado de SameSite en la red con la cookie. La propiedad HttpCookie.Secure o "requireSSL" de los archivos de configuración se puede usar para marcar la cookie como Secure o no.

Las nuevas instancias de HttpCookie tendrán como valor predeterminado SameSite=(SameSiteMode)(-1) y Secure=false. Estos valores predeterminados se pueden invalidar en la sección de configuración de system.web/httpCookies, donde la cadena "Unspecified" es una sintaxis sencilla de solo 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 propiedades SameSite y Secure como cualquier otra instancia HttpCookie. Sin embargo, debido a la aparición de parches del estándar SameSite, las opciones de configuración de estas cuatro características son incoherentes. 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 se revertirá 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 estos momentos. 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 este contenido en un idioma que no es el inglés, díganos si le gustaría que los comentarios sobre el código estuviesen en escritos en su idioma. Puede hacerlo en este artículo de discusión de GitHub.

Redestinar aplicaciones .NET

Para tener como destino .NET 4.7.2 o posterior:

  • Asegúrese de que web.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 propiedad TargetFrameworkVersion correcta:

    <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 destinados 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 packages.config anterior, el paquete Microsoft.ApplicationInsights:

    • Está destinado a .NET 4.5.1.
    • Debe tener actualizado su atributo targetFramework a net472 si existe un paquete actualizado destinado al destino de la plataforma.

Versiones anteriores a la .NET 4.7.2

Microsoft no admite versiones de .NET inferiores a la 4.7.2 para escribir el atributo de cookie del mismo 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 de revisión de diciembre

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

  • Antes de aplicar una revisión a un valor de None significa:
    • No emitir el atributo en absoluto.
  • Después de la revisión:
    • Un valor de None significa "Emitir el atributo con un valor de None".
    • Un valor SameSite 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 el cambio en los exploradores

Si instala la revisión y emite una cookie con SameSite.None, se producirá una de estas dos cosas:

  • 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 antigua dice:
    • Si ve un valor que no entiende, ignórelo y cambie a restricciones estrictas del mismo sitio.

Por lo tanto, la aplicación se interrumpe en Chrome o se rompe en muchos otros lugares.

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 han actualizado .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, consulte artículos de KB que admiten SameSite en .NET Framework.

El borrador de 2019 de la especificación SameSite:

  • No es compatible 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 que las cookies que afirman explícitamente SameSite=None para habilitar la entrega entre sitios deben estar también marcadas como Secure.
  • Es compatible con las revisiones emitidas como se describe en la lista anterior de KB.
  • 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 presenta algunos cambios que pueden ser importantes.

  • Las cookies de autenticación de formularios y estado de sesión ahora se escriben en la red como Lax en lugar de sin especificar.
    • Aunque la mayoría de las aplicaciones funcionan con cookies de SameSite=Lax, las aplicaciones que POST en sitios o aplicaciones que usan iframe pueden encontrar que su estado de sesión o las cookies de autorización de formularios no se usan según lo previsto. Para solucionarlo, cambie el valor cookieSameSite de la sección de configuración adecuada, como se explicó anteriormente.
  • HttpCookies que establecen SameSite=None explícitamente en código o 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 exploradores que admiten el borrador estándar 2019 con cookies de SameSite=None, recuerde también marcarlas en Secure o no puede que no se reconozcan.
    • Para revertir al comportamiento 2016 de no escribir SameSite=None, use la configuración de la aplicación aspnet:SupressSameSiteNone=true. Tenga en cuenta que esto se aplicará a todos los HttpCookies de la aplicación.

Consulte Azure App Service: Revisión de cookies de SameSite y .NET Framework 4.7.2 para obtener información sobre cómo Azure App Service configura los 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 atributo sameSite=None 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 el consejo de Google está limitado. Algunos navegadores, especialmente los navegadores móviles tienen límites muy pequeños en cuanto al número de cookies que puede enviar un sitio o un nombre de dominio. El envío de varias cookies, especialmente 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 de aplicaciones difíciles de diagnosticar y corregir. Además, como marco existe 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 admiten el estándar 2016 y para los que el atributo debe quitarse por completo. No está pensado como una implementación completa:

  • Es posible que la aplicación vea exploradores que nuestros sitios de prueba no.
  • 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 sobre cookies de SameSite ASP.NET 4.7.2:

Asegurarse de que el sitio redirige a HTTPS

Para ASP.NET 4.x, WebForms y MVC, la característica Reescritura de direcciones URL de IIS se puede usar 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 Reescritura de direcciones URL de IIS es una característica opcional que puede necesitar la instalación.

Probar aplicaciones para problemas de SameSite

Debes probar tu aplicación con los navegadores que admitas y repasar 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 la 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 marcas de características de participación que se pueden usar para las 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+ permite 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, 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 próximo comportamiento de las cookies que no tienen habilitado el atributo sameSite. Chrome 80 está en el destino para realizar el cambio para tratar las cookies sin el atributo como SameSite=Lax, aunque con un período de gracia temporal para determinadas solicitudes. Para deshabilitar el período de gracia, 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 explorador sobre la falta de atributos sameSite. Use F12 para abrir la consola del explorador.

Prueba con Safari

Safari 12 aplica estrictamente el proyecto anterior y falla cuando el nuevo valor None 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 de estilo del sistema operativo basados en Safari 12, Safari 13 y WebKit mediante MSAL, ADAL o cualquier biblioteca que esté usando. 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 actualmente una marca de participació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 explorador 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)

Las marcas 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 Microsoft Teams es Chromium 66, que exhibe el comportamiento anterior. Realice sus propias pruebas de compatibilidad con la versión de Electron que use el producto. Consulte Compatibilidad con exploradores más antiguos.

Revertir las revisiones de SameSite

Puede revertir el comportamiento actualizado sameSite en las aplicaciones de .NET Framework a su comportamiento anterior, donde no se emite el atributo sameSite 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