Cross-site request forgery (CSRF)

Un navegador adjunta las cookies según el destino de la petición, no según la página que la lanzó. Si un endpoint cambia estado y lo único que demuestra quién pregunta es una cookie de sesión, cualquier página de Internet puede provocar ese cambio: pinta un formulario apuntando al objetivo, lo envía con script, y el navegador adjunta la cookie al salir. El atacante no llega a leer la respuesta y no le hace falta, porque el daño es la escritura.

Hay dos controles que lo cierran. Un token anti-CSRF ata cada petición a un valor que la página atacante no puede leer ni adivinar, porque la política del mismo origen le impide leer el HTML del objetivo. El atributo de cookie SameSite impide que la cookie llegue siquiera a adjuntarse a peticiones de otro sitio, y por eso los atributos de seguridad de las cookies son lo primero que hay que leer.

Los navegadores principales tratan hoy una cookie sin atributo SameSite como Lax, así que el ataque de manual contra un POST de formulario ya no es el caso común. Lo que seguimos encontrando son los bordes. La navegación de primer nivel por GET sigue llevando la cookie bajo Lax, así que cualquier endpoint que cambie estado en un GET sigue siendo explotable. Algunos navegadores mantienen una ventana de gracia corta desde que se emite la cookie durante la cual un POST desde otro sitio todavía la lleva. A los endpoints que aceptan los tipos de contenido simples, codificación de formulario o texto plano, se puede llegar con un formulario de otro sitio sin preflight, lo que pilla a las APIs que daban por hecho que el navegador lo pararía. Un token que se genera pero no se verifica nunca, o que se verifica solo cuando resulta que viene, no es un control. Y el cross-site scripting derrota todas las defensas de CSRF a la vez, porque un script que corre en el origen puede leer el token.

Lo probamos cogiendo una petición autenticada real, quitando o alterando el token, repitiéndola desde otro origen y comprobando después si el estado cambió de verdad en el servidor, en lugar de si la respuesta parecía un error. La evidencia en el informe es el registro de antes y de después, no una captura de un proxy. La severidad va detrás de la acción: una petición falsificada que cambia una dirección de correo es un camino a la toma de control de la cuenta, y una que cambia una preferencia de visualización es una observación. Esto forma parte de cómo probamos las peticiones que cambian estado en una aplicación web.