Análisis de las Same-site cookies contra ataques CSRF

Las vulnerabilidades de CSRF

Las vulnerabilidades de tipo Cross-site request forgery (CSRF) son extremadamente frecuentes en aplicaciones web. A pesar de que se conocen desde hace mucho tiempo, estamos acostumbrados a encontrarlas constantemente en el top 10 OWASP de vulnerabilidades más importantes.

Los ataques CSRF se basan en el hecho de que las cookies asociadas a un dominio son enviadas automáticamente por el navegador en las peticiones dirigidas hacia ese dominio, independientemente de su origen.

Esta situación implica que un atacante, a pesar de no conocer el valor de las cookies de un usuario sobre una web, es capaz de forzar peticiones hacia ella desde un dominio externo (peticiones “cross-site”) que contienen los valores adecuados.

Si la aplicación no cuenta con las medidas de protección correspondientes, el atacante podrá utilizar ataques CSRF para forzar acciones de manipulación de datos sobre una web vulnerable bajo la sesión de la víctima.

Cookies Same-site

Para intentar mitigar los problemas de seguridad asociados al comportamiento descrito, algunos navegadores han comenzado a implementar soporte para el nuevo flag SameSite. Básicamente, esta nueva funcionalidad puede ser utilizada para impedir que el navegador envíe automáticamente una determinada cookie cuando la petición se origina desde un dominio externo.

Al igual que se hace con los flags HttpOnly y Secure, el flag SameSite puede ser activado estableciendo la cabecera correspondiente en las respuestas HTTP del servidor web:

Set-Cookie: MiCookie=valor; HttpOnly; Secure; SameSite=Strict

La incorporación de esta nueva medida puede ser útil para lograr varios objetivos:

• Protección contra ataques CSRF.
• Protección contra ataques basados en el tiempo de respuesta de peticiones “cross-domain”, como “Pixel-perfect Timing Attacks”.
• Protección contra ataques de Cross-site script inclusion – XSSI (no contra XSS).
• Además, este flag puede contener un valor añadido en relación con las políticas de privacidad, ya que una página web podría ofrecerlo al usuario como una garantía de que sus cookies no serán utilizadas con fines de rastreo en la navegación.

Existen dos valores posibles para el flag SameSite, cada uno con diferentes comportamientos:

• Strict: Las cookies establecidas con este valor serán enviadas solo en las peticiones que se han originado desde el propio dominio. Este es, por tanto, el valor más restrictivo.
• Lax: En este caso, se permitirá además al navegador enviar la cookie en algunas peticiones originadas desde dominios externos. Concretamente, permitirá su envío en peticiones “top-level” de tipo GET, es decir, peticiones en las que cambia visiblemente la URL en la barra de navegación. Este hecho no se produce en peticiones GET producidas, por ejemplo, por la carga de imágenes, iframes, o peticiones ajax, sobre las cuales se restringirá el envío de las cookies establecidas con este valor del flag.

Cabe mencionar que las cookies marcadas con el flag Lax podrán ser enviadas en peticiones GET generadas con funcionalidades de “prerendering” como <link rel=”prerender” href=”…”> o con ventanas emergentes, ya que no generan peticiones “cross-domain”. En estas acciones, el usuario no tiene por qué percibir un cambio en la URL de navegación de la ventana actual.

Consideraciones de las cookies Samesite

Tal como se indica en la propia especificación formal, este nuevo flag debe ser considerado como una medida de apoyo a las protecciones habituales, de manera que contribuya a establecer una defensa en profundidad.

Lo primero que se debe tener en cuenta es que, actualmente, solo un mínimo porcentaje de navegadores implementan soporte para Same-site cookies, por lo que la nueva funcionalidad debe ser entendida como una medida de protección real a largo plazo.

Es interesante comentar que todos los navegadores populares ya implementan, desde hace tiempo, la opción de no permitir las cookies de terceros.

Marcar esta opción sería equivalente a establecer el atributo “SameSite=Strict” por defecto en todas las cookies y, por tanto, conlleva invulnerabilidad contra ataques CSRF. Sin embargo, aplicar esta medida puede afectar negativamente a la experiencia de navegación, ya que existen muchos casos de uso legítimos en donde entran en juego las cookies de terceros. Por ejemplo, evitan que nos tengamos que autenticar cada vez que accedemos a una página desde otro dominio, son vitales para el funcionamiento de widgets, nos permiten comentar en muchas webs utilizando nuestras cuentas de Google, Facebook, etc.

Las cookies Same-site permiten, por tanto, llevar a cabo una restricción selectiva y adecuada por parte del servidor para cada caso particular. De hecho, puede ser interesante definir múltiples cookies de sesión para las cuales se asignen los valores de Lax o Strict dependiendo de las necesidades de uso de cada una.

En ocasiones, las aplicaciones web permiten llevar a cabo peticiones POST (u otro tipo de métodos) mediante métodos GET, trasladando los parámetros a la URL. Si el desarrollador no ha tenido en cuenta este hecho, un atacante podrá aprovecharlo para evadir la protección de cookies Same-site establecidas con el atributo Lax.

Finalmente, hay que tener en cuenta que ninguna medida protegerá de poder forzar acciones provocadas por un tercero si existen otras vulnerabilidades como, por ejemplo, Cross-site scripting (XSS).

Conclusiones

Las cookies Same-site pueden proporcionar una protección efectiva contra ataques CSRF sin afectar negativamente a la funcionalidad de la aplicación.

Para ello, debe extenderse el uso de navegadores que implementen esta nueva característica. Asimismo, los servidores deben enviar en las respuestas HTTP los valores adecuados sobre las cookies Same-site para cada caso de uso, y se deben seguir aplicando las medidas de protección habituales sobre otro tipo de vulnerabilidades que pudieran ser empleadas para evadir la protección.

Descubre nuestro trabajo y nuestros servicios de ciberseguridad en www.tarlogic.com/es/

En TarlogicTeo y en TarlogicMadrid.