El CSRF: la acción forzada sin que usted lo sepa

El atacante empieza por localizar una petición que modifica algo en un servicio y luego fabrica una dirección o un script que la reproduce con sus propios valores. OWASP pone el ejemplo de un banco ficticio: la petición legítima transfiere 100 dólares a un beneficiario, y el atacante se pone a sí mismo como beneficiario y aumenta el importe¹.

Falta conseguir que la víctima cargue esa petición mientras tiene la sesión iniciada. Se citan dos métodos: un correo no solicitado con contenido HTML, o una trampa colocada en páginas que la víctima probablemente visite mientras usa su servicio en línea¹.

El ataque también puede quedar almacenado en el propio sitio vulnerable, por ejemplo en un campo que acepta HTML. Entonces resulta más probable: la víctima consulta con más gusto una página del sitio que una página cualquiera de Internet, y además ya tiene allí la sesión iniciada¹.

A menudo, nada. El enlace trampa puede disfrazarse de enlace corriente, con un texto como «ver mis fotos». También puede adoptar la forma de una falsa imagen de tamaño cero: si aparece en un correo, la víctima no ve nada, pero el navegador envía igualmente la petición, sin ninguna señal visual de que la operación se ha realizado¹.

Ilustración neutralizada, no es una dirección real.
Enlace disfrazado: texto mostrado «Ver mis fotos», dirección oculta
hxxp://banque[.]exemple[.]invalid/virement?dest=[cuenta del atacante]&montant=[elevado]
Variante: imagen invisible en un correo, cargada sin hacer clic.

Si el servicio espera una petición de tipo POST, el atacante puede alojar en su sitio un formulario con campos ocultos. La víctima cree que hace otra cosa y pulsa, o bien un script lo envía automáticamente al cargar la página¹. En ambos casos, la página que se muestra es corriente y la acción se desarrolla en otra parte.

El mecanismo se basa en un comportamiento normal de los navegadores. Guardan las cookies emitidas por una aplicación, entre ellas las cookies de sesión de los usuarios autenticados, y envían todas las cookies de un dominio en cada petición, sea cual sea la forma en que esa petición nació en el navegador². Las cookies no son lo único implicado: las autenticaciones de tipo Basic y Digest también son vulnerables, porque el navegador reenvía automáticamente las credenciales hasta el final de la sesión².

Según OWASP, varias ideas de defensa no funcionan¹:

• una cookie secreta, ya que todas las cookies se envían con cada petición;
• aceptar solo peticiones POST, ya que basta un formulario oculto para falsificar una;
• las transacciones en varios pasos, mientras el atacante pueda prever cada paso;
• la sola comprobación de la cabecera Referer, porque puede falsificarse y a veces falta por razones de privacidad.

Las protecciones recomendadas, en el lado de la aplicación, son las siguientes.

• Comprobar primero si el framework ya ofrece una protección CSRF y usarla. Si no, añadir tokens anti-CSRF a todas las peticiones que modifican el estado y validarlos en el servidor³. Sin token, el atacante no puede fabricar una petición válida³.
• Para el software sin estado, usar una cookie de doble envío, preferiblemente firmada³.
• Establecer el atributo SameSite en las cookies de sesión³. Con el valor strict, el navegador no envía la cookie en las peticiones entre sitios, ni siquiera al seguir un enlace corriente. Con lax, la envía al seguir un enlace desde otro sitio, pero la retiene en los métodos expuestos al CSRF, como POST⁴. Con none, no se ofrece ninguna protección⁴.
• Controlar el origen con las cabeceras estándar, en particular Sec-Fetch-Site, compatible con todos los grandes navegadores desde marzo de 2023³.
• No usar peticiones GET para operaciones que modifican el estado³.

Estas medidas tienen límites. SameSite=Lax deja pasar las peticiones GET de navegación de nivel superior: un punto de acceso que modifica el estado mediante GET sigue siendo vulnerable². Los navegadores antiguos pueden no aplicar SameSite². Y un fallo XSS puede eludir todas las protecciones anti-CSRF; el gusano Samy, por ejemplo, usó un XMLHttpRequest para obtener el token CSRF y falsificar peticiones¹³. El comportamiento por defecto de SameSite varía: en diciembre de 2024, lax era el valor por defecto de Chrome, Edge y Opera, pero de ninguna versión de Firefox ni de Safari, de ahí el consejo de fijarlo de forma explícita⁴.

2008: el exploit de uTorrent

OWASP cita, como ejemplo real de ataque CSRF contra una aplicación que funciona mediante peticiones GET, un exploit dirigido a uTorrent que data de 2008. Se utilizó a gran escala para descargar software malicioso¹. La fuente no dice más: ni el número de víctimas ni el modo de difusión.

Fallos catalogados por el CWE (identificadores de 2004 a 2009)

El CWE-352 ofrece una lista seleccionada de ejemplos observados, que no es exhaustiva⁵. Varios se basan en una simple URL dentro de una etiqueta img: CVE-2004-1703 y CVE-2004-1995 permiten añadir cuentas de usuario, y CVE-2004-1842 obtener privilegios de administrador⁵. Otros afectan a la propia administración: CVE-2009-3520 permite modificar la contraseña del administrador, y CVE-2009-3759 cambiar contraseñas o apagar una máquina virtual desde una interfaz web⁵.