Eludir SameSite en cookies mediante iframes y técnicas poco conocidas que no aparecen en las guías

La configuración SameSite en la cookie ya se ha convertido en una de las principales herramientas para proteger sitios web contra ataques relacionados con peticiones entre sitios — por ejemplo, CSRF. Pero, como suele ocurrir, las reglas de los navegadores se pueden eludir, sobre todo si se combina un poco de creatividad, APIs antiguas y varias formas inesperadas de enviar la petición. Hoy explicamos cómo los atacantes usan iframes y técnicas no evidentes para eludir SameSite, y por qué esto sigue siendo un problema incluso en 2025.

Qué es SameSite y para qué sirve

SameSite es un atributo de la cookie que determina si se puede enviar la cookie en solicitudes entre dominios. La idea es simple: si su sitio establece la cookie con SameSite=Strict o SameSite=Lax, el navegador no las enviará si la solicitud proviene de otro dominio. Esto cierra un amplio espectro de ataques, especialmente CSRF.

Valores posibles:

• Strict — las cookies se envían solo al navegar dentro del mismo dominio.
• Lax — las cookies se envían al seguir enlaces o al cargar páginas, pero no en la mayoría de las solicitudes desde otros sitios.
• None (requiere Secure) — las cookies se envían siempre, incluidas las solicitudes entre dominios.

Sobre el papel suena fiable. Pero en la práctica, como muestra la experiencia, las restricciones de SameSite se pueden evitar si se conocen las «vulnerabilidades» que dejan los mecanismos web históricos.

Por qué eludir SameSite sigue siendo posible

Hay varias razones:

1. Diferentes navegadores implementan SameSite con matices — las versiones antiguas pueden comportarse según reglas previas.
2. Algunas APIs y elementos HTML funcionan de forma «especial», haciendo que el navegador envíe cookies incluso en una petición entre dominios.
3. Los desarrolladores a menudo confían solo en SameSite y olvidan medidas adicionales de protección.

Un ejemplo clásico: un sitio protegido contra CSRF con SameSite=Lax, pero un atacante encuentra forma de incrustar la página de la víctima en un iframe con los parámetros adecuados y ejecutar la solicitud desde dentro.

Cómo los iframes ayudan a eludir SameSite

El iframe es una ventana incrustada en el navegador que carga otro sitio. Crea un contexto completo donde el navegador a menudo actúa como si el usuario estuviera interactuando directamente con ese sitio. Y ahí comienza la «magia».

Escenario con una solicitud GET

Si en el sitio protegido existe una funcionalidad que realiza alguna acción por una solicitud GET (por ejemplo, confirma una operación o ejecuta una búsqueda), se puede abrir en un iframe. En algunos casos el navegador enviará las cookies incluso con SameSite=Lax, porque se interpretará como una «navegación».

<iframe src="https://target-site.com/action?approve=true" style="display:none"></iframe>

Sí, en las versiones recientes de Chrome y Firefox esto se ha limitado, pero en condiciones reales la elusión aún aparece, sobre todo en redes corporativas con navegadores obsoletos.

Interacción mediante postMessage

El iframe no solo sirve para cargar páginas, sino también para comunicarse entre ventanas mediante postMessage. Un atacante puede cargar la página de la víctima en un iframe y luego, desde un script en la ventana principal, iniciar acciones que eludan las restricciones de SameSite.

Métodos inusuales de elusión que rara vez se mencionan

Aparte de los iframes, existen técnicas más exóticas:

• Protocolos como data: y blob: — se puede envolver contenido malicioso en una fuente no estándar para que el navegador interprete el origen de otra manera.
• Incrustación mediante SVG — el elemento <image> dentro de SVG a veces transmite cookies en contra de lo esperado.
• Service Workers — permiten interceptar solicitudes y «reensamblarlas» de modo que SameSite no funcione como se espera.
• Carga forzada de recursos (CSS, JS) con parámetros a los que responde el servidor.

Ejemplo de una elusión compleja

Supongamos que un atacante quiere eludir SameSite=Strict en el sitio de un banco. Cuenta con:

• Un dominio desde el que se puede incrustar un iframe.
• Una URL conocida en el sitio del banco que por una solicitud GET ejecuta una acción (por ejemplo, confirma una transferencia).
• Una vulnerabilidad tipo XSS en otro subdominio del banco.

Cómo podría funcionar:

1. El iframe carga el subdominio con la XSS.
2. El script XSS en el subdominio envía una solicitud al dominio principal (API bancaria).
3. Como se trata de una interacción «interna», el navegador envía las cookies, ignorando SameSite para los subdominios.
4. La solicitud ejecuta la acción en nombre de la víctima.

Cómo protegerse

Si es desarrollador o administrador, confiar solo en SameSite es peligroso. Algunas medidas:

• Agregar tokens CSRF en todas las solicitudes críticas.
• Usar Content Security Policy para limitar las fuentes desde las que se pueden cargar recursos e iframes.
• Comprobar Origin y Referer en el servidor.
• Impedir la integración del sitio mediante iframe con el encabezado X-Frame-Options: DENY o frame-ancestors 'none'.
• Actualizar los navegadores y probar en versiones antiguas.

Conclusión

SameSite es una herramienta útil, pero no una bala de plata. Los iframes y técnicas raras de elusión muestran que la web aún conserva muchas peculiaridades «históricas» que pueden aprovecharse en un ataque. Sin una protección integral (tokens CSRF, verificación de encabezados, restricciones de integración) confiar en una sola configuración de cookie es como poner una cerradura en la puerta pero dejar una ventana abierta.