Schemeful Same-Site modifica la definición de un sitio web

Este artículo forma parte de una serie sobre los cambios del atributo de cookies SameSite:

Schemeful Same-Site modifica la definición de un sitio (web) de solo el dominio registrable al esquema + dominio registrable. Puedes encontrar más información y ejemplos en Información sobre «same-site» y «same-origin».

Término clave: Esto significa que la versión HTTP insegura de un sitio, por ejemplo, http://website.example, y la versión HTTPS segura de ese sitio, https://website.example, ahora se consideran entre sitios.

La buena noticia es que, si tu sitio web ya fue totalmente actualizado a HTTPS, no necesitas preocuparte por nada. Nada cambiará para ti.

Si todavía no has actualizado totalmente tu sitio web, esa debería ser tu prioridad. Sin embargo, si hay casos en los que los visitantes de tu sitio van a elegir entre HTTP y HTTPS, algunos de esos escenarios comunes y el comportamiento de las cookies SameSite asociadas se describen a continuación.

Advertencia: El plan a largo plazo es eliminar gradualmente la asistencia a cookies de terceros por completo y reemplazarlas con alternativas que preserven la privacidad. Configurar SameSite=None; Secure en una cookie para permitir que se envíe entre esquemas solo debería considerarse una solución temporal en la migración hacia el HTTPS completo.

Puedes habilitar estos cambios para realizar la prueba tanto en Chrome como en Firefox.

  • Desde Chrome 86, habilita chrome://flags/#schemeful-same-site. Realiza un seguimiento del progreso en la página de estado de Chrome.
  • Desde Firefox 79, configura network.cookie.sameSite.schemeful como true mediante about:config. Realiza un seguimiento del progreso mediante la edición Bugzilla.

Una de las razones principales para cambiar a SameSite=Lax como la configuración predeterminada para cookies fue protegerse contra la falsificación de solicitudes entre sitios (CSRF). Sin embargo, el tráfico HTTP inseguro aún presenta una oportunidad para que los atacantes de la red falsifiquen las cookies que, luego, serán usadas en la versión HTTPS segura del sitio. Crear este límite entre sitios adicional entre esquemas proporciona una mayor defensa ante estos ataques.

Escenarios entre esquemas comunes 

Término clave: En los siguientes ejemplos en los que las URL tienen el mismo dominio registrable, p. ej., site.example, pero diferentes esquemas, por ejemplo, http://site.example frente a https://site.example, se utiliza la denominación entre esquemas.

Navegar entre versiones entre esquemas de un sitio web (por ejemplo, establecer vínculos desde http://site.example y https://site.example) antes permitía que se enviaran cookies SameSite=Strict. Ahora, esto se trata como una navegación entre sitios, lo que significa que las cookies SameSite=Strict se bloquearán.

Una navegación entre esquemas activada al seguir un vínculo en la versión HTTP insegura de un sitio a la versión HTTPS segura. SameSite=Strict cookies blocked, SameSite=Lax and SameSite=None; Secure cookies are allowed.
Navegación entre esquemas de HTTP a HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqueado ⛔ Bloqueado
SameSite=Lax ✓ Permitido ✓ Permitido
SameSite=None;Secure ✓ Permitido ⛔ Bloqueado

Cargando subrecursos 

Advertencia: Todos los navegadores populares bloquean el contenido mixto activo como las secuencias de comando y los iframes. Además, los navegadores, incluidos Chrome y Firefox, trabajan para lograr la actualización o el bloqueo del contenido mixto pasivo.

Cualquier cambio que hagas aquí se considerará una solución temporal mientras trabajas para actualizar por completo a HTTPS.

Entre los ejemplos de subrecursos, se incluyen imágenes, iframes y solicitudes de red realizadas con XHR o Fetch.

Antes, cargar un subrecurso entre esquemas en una página habría permitido que las cookies SameSite=Strict o SameSite=Lax se enviaran o configuraran. Ahora, esto se trata de la misma forma que cualquier otro subrecurso de terceros o entre sitios, lo que significa que cualquier cookie SameSite=Strict o SameSite=Lax se bloqueará.

Además, incluso si el navegador permite que se carguen recursos de esquemas inseguros en una página segura, se bloquearán todas las cookies en estas solicitudes, ya que las cookies de terceros o entre sitios requieren Secure.

Un subrecurso entre esquemas que resulta de un recurso proveniente de la versión HTTPS segura del sitio que se incluyó en una versión HTTP insegura. SameSite=Strict and SameSite=Lax cookies blocked, and SameSite=None; Secure cookies are allowed.
Una página HTTP que incluye un subrecurso entre esquemas mediante HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqueado ⛔ Bloqueado
SameSite=Lax ⛔ Bloqueado ⛔ Bloqueado
SameSite=None;Secure ✓ Permitido ⛔ Bloqueado

Publicar un formulario 

Antes, publicar entre versiones entre esquemas de un sitio permitía que las cookies configuradas con SameSite=Lax o SameSite=Strict se enviaran. Ahora, esto se trata como una publicación entre sitios: solo pueden enviarse cookies SameSite=None. Tal vez encuentres este escenario en sitios que presentan la versión insegura de manera predeterminada, pero los usuarios se actualizan a la versión segura al enviar el formulario de acceso o salida.

Como ocurre con los subrecursos, si la solicitud va de un contexto seguro, p. ej., HTTPS, a uno inseguro, p. ej., HTTP, se bloquearán todas las cookies en estas solicitudes, ya que las cookies de terceros o entre sitios requieren Secure.

Advertencia: La mejor solución aquí es asegurar que tanto la página de formulario como el destino estén en una conexión segura como HTTPS. Esto es particularmente importante si el usuario está ingresando información confidencial en el formulario.

Envío de un formulario entre esquemas que resulta de un formulario en una versión HTTP insegura y se envía a una versión HTTPS segura. SameSite=Strict and SameSite=Lax cookies blocked, and SameSite=None; Secure cookies are allowed.
Envío de formulario entre esquemas de HTTP a HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqueado ⛔ Bloqueado
SameSite=Lax ⛔ Bloqueado ⛔ Bloqueado
SameSite=None;Secure ✓ Permitido ⛔ Bloqueado

¿Cómo puedo probar mi sitio? 

Las herramientas para desarrolladores y la mensajería están disponibles en Chrome y Firefox.

Desde Chrome 86, la pestaña Error en DevTools incluirá errores Schemeful Same-Site. Puedes ver los siguientes errores destacados para tu sitio.

Errores de navegación:

  • «Migrar por completo a HTTPS para que las cookies se sigan enviando en solicitudes del mismo sitio» es una advertencia de que la cookie se bloqueará en una versión futura de Chrome.
  • «Migrar por completo a HTTPS para que las cookies se envíen en solicitudes del mismo sitio» es una advertencia de que la cookie se ha bloqueado.

Errores de carga de subrecursos:

  • «Migrar por completo a HTTPS para que las cookies se sigan enviando en subrecursos del mismo sitio» o «Migrar por completo a HTTPS para seguir permitiendo que las cookies se envíen a subrecursos del mismo sitio» son advertencias de que la cookie se bloqueará en una versión futura de Chrome.
  • «Migrar por completo a HTTPS para que las cookies se envíen a subrecursos del mismo sitio» o «Migrar por completo a HTTPS para permitir que las cookies se envíen mediante subrecursos del mismo sitio» son advertencias de que la cookie se ha bloqueado. Esta última advertencia también puede aparecer al publicar un formulario.

Hay más información disponible en Sugerencias de pruebas y depuración para Schemeful Same-Site.

Desde Firefox 79, con network.cookie.sameSite.schemeful configurado como true mediante about:config, la consola mostrará un mensaje para los errores de Schemeful Same-Site. Tal vez veas lo siguiente en tu sitio:

  • «La cookie cookie_name pronto se tratará como una cookie entre sitios en oposición a http://site.example/ porque el esquema no coincide».
  • «La cookie cookie_name se ha tratado como entre sitios en oposición a http://site.example/ porque el esquema no coincide».

Preguntas frecuentes 

Mi sitio ya está disponible por completo en HTTPS; ¿por qué veo errores en DevTools de mi navegador? 

Es posible que algunos de tus vínculos y sus recursos aún apunten a URL inseguras.

Una forma de solucionar este error es usar HTTP con Seguridad de Transporte Estricta (HSTS) y la directiva includeSubDomain. Con HSTS + includeSubDomain, incluso si una de tus páginas incluye un vínculo inseguro por accidente, el navegador usará en su lugar la versión segura automáticamente.

¿Qué tal si no puedo actualizar a HTTPS? 

Si bien recomendamos enfáticamente que actualices tu sitio completo a HTTPS para proteger a tus usuarios, si no puedes hacerlo solo, te sugerimos que hables con tu proveedor de hosting para ver si te ofrece esa opción. Si usas tu propio host, entonces Let’s Encrypt proporciona herramientas para instalar y configurar un certificado. También puedes investigar la posibilidad de mover tu sitio a CDN o a otro proxy que pueda proporcionar la conexión HTTPS.

Si eso tampoco es posible, intenta disminuir la protección SameSite en las cookies afectadas.

  • En los casos donde solo las cookies SameSite=Strict se bloquean, puedes disminuir la protección a Lax.
  • En los casos donde tanto las cookies Strict como Lax se bloquean y tus cookies se envían a una URL segura o se configuran desde una, puedes disminuir las protecciones a None.
    • Esta solución alternativa fallará si la URL a la que envías las cookies (o desde donde las configuras) es insegura. Esto se debe a que SameSite=None requiere el atributo Secure en las cookies, lo cual significa que esas cookies podrían no enviarse ni configurarse a través de una conexión insegura. En ese caso, no podrás acceder a esa cookie hasta que tu sitio se actualice a HTTPS.
    • Recuerda que esto es solo temporal, ya que las cookies de terceros se eliminarán por completo.

¿Cómo afecta esto a mis cookies si no especifiqué un atributo SameSite? 

Las cookies sin un atributo SameSite se tratan como si especificaran SameSite=Lax y el mismo comportamiento entre esquemas se aplica a ellas. Ten en cuenta que la excepción temporal para métodos poco seguros aún se aplica. Para obtener más información, consulta la mitigación Lax + POST en las preguntas frecuentes de ChromiumSameSite.

¿Cómo resultan afectadas las WebSockets? 

Las conexiones WebSocket aún se considerarán del mismo sitio si están en la misma seguridad que la página.

Mismo sitio:

  • Conexión wss:// desde https://
  • Conexión ws:// desde http://

Entre sitios:

  • Conexión wss:// desde http://
  • Conexión ws:// desde https://

Fotografía de Julissa Capdevilla en Unsplash


Source: Google Dev

Deja un comentario