Photo by Mohammad Rahmani on Unsplash
A partir de la versión 84, Chrome establece por defecto el atributo SameSite de las Cookies en Lax. Los servicios que utilizan Third-party cookies pueden verse afectados si no han configurado SameSite correctamente.
Resumen
Las Cookies son mecanismos utilizados en los servicios web para almacenar el estado, comúnmente utilizados para mantener sesiones de inicio de sesión, carritos de compra, seguimiento de anuncios, etc. Sin embargo, el uso generalizado de las Cookies también conlleva preocupaciones de privacidad y seguridad, y SameSite se introdujo para abordar estos problemas.
First-Party and Third-Party
Basado en la fuente de la Cookie (Set-Cookie), cada Cookie tiene un Dominio específico. Al mirar la URL actual en el navegador del usuario, si el Dominio de la Cookie coincide con la URL actual, es First-Party; de lo contrario, es Third-Party.
Third-party
Por ejemplo, al navegar por el sitio a.com, se envía una solicitud (request) a third-party.com y se recibe una Cookie de third-party.com. Dado que el navegador incluye automáticamente las Cookies con el mismo Dominio en las solicitudes, si luego navegas por otro sitio como b.com y este también envía una solicitud a third-party.com, el servidor recibirá la Cookie. Para estos dos sitios, la Cookie de third-party.com es Third-party.
First-party
Si navegas por un sitio web que coincide con el Dominio third-party.com, la Cookie también se enviará. En este caso, esta Cookie se llama First-party.
Same-Origin and Same-Site
El ejemplo anterior mencionaba el uso del Dominio para determinar el tipo de Cookie, pero una mejor manera de decirlo es determinando si el Sitio (Site) es el mismo. ¿Se relaciona esto con el Same-origin que se ve con frecuencia?
Origin
Origin se compone de Scheme, Host y Port. El método de determinación es muy simple: si el Scheme, Host y Port de dos URL son todos idénticos, son Same-origin; de lo contrario, son Cross-origin.
Site
La determinación de Same-Site implica Effective top-level domains (eTLDs). Todos los eTLDs se definen en la Public Suffix List, y un Sitio se compone de un eTLD más un prefijo.
Por ejemplo:
github.io existe en la Public Suffix List. Agregar un prefijo (por ejemplo, a.github.io) lo convierte en un Sitio. Por lo tanto, a.github.io y b.github.io son dos Sitios diferentes (Cross-site).
example.com no existe en la Public Suffix List, pero .com sí, por lo que example.com es un Sitio, y a.example.com y b.example.com son el mismo Sitio (Same-site).
Ten en cuenta que el Sitio no incluye el Puerto, por lo que incluso si los Puertos son diferentes, pueden seguir siendo Same-site.
Why SameSite?
El mecanismo donde “cualquier Solicitud lleva cookies de ese Dominio” también trajo problemas de seguridad y otros, siendo el más importante el Cross-site request forgery (CSRF).
CSRF
Supongamos que un usuario ha iniciado sesión en example.com y ha obtenido una Cookie. Cuando el usuario navega por un sitio malicioso evil.com, el JavaScript en ese sitio puede enviar una Solicitud POST a example.com/pay?amount=1000. El navegador incluirá automáticamente la Cookie de example.com, y el usuario paga 1000 dólares sin saberlo. El Servidor no puede determinar de dónde proviene esta Solicitud (Request).
Limitaciones
Las Cookies en sí mismas no se pueden configurar para enviarse solo en un entorno First-party, por lo que las Solicitudes llevan Cookies en cualquier entorno. El Servidor no puede identificar la fuente de la Solicitud y solo puede responder como de costumbre, lo que hace que el Cliente desperdicie ancho de banda enviando Cookies inútiles.
Solución
Con el atributo SameSite, podemos configurar individualmente las condiciones para enviar Cookies en diferentes entornos.
SameSite
El atributo SameSite tiene tres valores. Establecerlo en Strict o Lax puede restringir las Cookies para que se envíen solo en Solicitudes Same-Site. Si se deja en blanco, el comportamiento depende del navegador; para Chrome, el valor predeterminado es Lax.
Strict
Las Cookies se envían solo en un entorno First-party. Sin embargo, hay un problema: supongamos que un usuario ve un enlace a una publicación de Facebook en example.com (digamos fb.com). Incluso si el usuario ha iniciado sesión en fb.com y tiene una Cookie, hacer clic en el enlace no enviará la Cookie porque los dos sitios son Cross-site, por lo que solo verán la página de inicio de sesión.
Por lo tanto, Strict es adecuado para acciones sensibles, como eliminar publicaciones, realizar pagos, etc.
Lax
Para abordar las limitaciones demasiado estrictas de Strict, Lax permite enviar Cookies incluso en situaciones Cross-site en los siguientes casos:
- Escribir una URL en la barra de direcciones
- Hacer clic en un enlace
<a href="..."> - Enviar un formulario
<form method="GET"> - Prerenderizado
<link rel="prerender" href="...">
Estos casos tienen dos puntos en común: todos son solicitudes GET y todos activan la Navegación de nivel superior (Top-level Navigation). Esto evita el problema de que Strict requiera iniciar sesión nuevamente cada vez, y también evita enviar Cookies sin saberlo al navegar por otros sitios web.
Lax + POST
Sin embargo, para evitar romper algunos flujos de inicio de sesión existentes, Chrome actualmente relaja ligeramente la restricción para SameSite=Lax, dando a los desarrolladores más tiempo para adaptarse.
Dentro de los dos minutos posteriores a la configuración de la Cookie, independientemente del Método de Solicitud (Request Method), siempre que active una navegación de página de nivel superior, se enviará la Cookie. Esto significa que si el navegador cambia de página, por ejemplo, enviando un formulario <form method="POST">.
Para más detalles, consulta el hilo sobre Lax + POST.
None
Para enviar una Third-party cookie, debes configurar SameSite=None; Secure. Sí, a partir de ahora, si quieres enviar una Third-party cookie en un entorno de prueba, por favor prepara https://localhost.
Además, enviar Cross-Origin Requests a través de XHR/Fetch requiere configurar withCredentials: true para enviar la Cookie y hacer efectivo el Set-Cookie en el encabezado de Respuesta. El Servidor también debe configurar Access-Control-Allow-Credentials: true en el encabezado de Respuesta para que JavaScript acceda al contenido de la Respuesta.
Navegadores No Compatibles
No todos los navegadores admiten las últimas reglas de SameSite todavía, por lo que se pueden agregar algunas soluciones temporales (Workarounds) en el Servidor para admitir varios navegadores:
Establecer Ambas Cookies
Este método puede resolver problemas para casi todos los navegadores, pero la desventaja es que habrá dos copias de la Cookie:
Set-cookie: name=value; SameSite=None; Secure
Set-cookie: name-legacy=value; Secure
Código del lado del servidor:
if (req.cookies['name']) {
// Usar la nueva si está disponible
cookieVal = req.cookies['name'];
} else if (req.cookies['name-legacy']) {
// De lo contrario, usar la antigua
cookieVal = req.cookies['name-legacy'];
}
User Agent
Determinar el navegador utilizando el User agent de la Solicitud para decidir el contenido de Set-Cookie. Este método solo requiere modificar el código que establece la Cookie, sin cambiar la parte de Análisis (Parsing). Sin embargo, este método de juicio implica más variables y hace que sea más fácil configurar la Cookie incorrecta.
Revisión
- Las Cookies sin el atributo SameSite establecido tendrán por defecto
SameSite=Laxyno se podrán enviaren un entorno Cross-site. - Para enviar Cookies en Cross-site, necesitas configurar
SameSite=None; Secure. - Puedes usar el SameSite sandbox para probar si tu navegador actual cumple con las últimas reglas de SameSite.