Glosario
Qué es CSRF (Cross-Site Request Forgery): hacer que un usuario con sesión iniciada actúe sin querer
CSRF (Cross-Site Request Forgery) usa el navegador de un usuario con sesión iniciada para enviar una solicitud que nunca quiso, como una transferencia. Cómo funciona y la defensa real: tokens CSRF, cookies SameSite y comprobación de Origin.
"Con solo abrir otro sitio mientras sigues con la sesión iniciada se dispara una transferencia o un cambio de configuración sin que lo sepas": eso es CSRF. Aquí tienes cómo funciona y cómo prevenirlo de forma fiable (sin pasos de ataque).
Por qué funciona (el mecanismo)
El navegador adjunta automáticamente las cookies de un sitio a las solicitudes dirigidas a ese sitio. Así que si un usuario tiene la sesión iniciada en su banco, una solicitud al banco disparada desde una página maliciosa sigue llevando "las cookies del usuario". Para el servidor, es indistinguible de una acción legítima.
Donde XSS "ejecuta código en el navegador de la víctima", CSRF "toma prestado el estado con sesión iniciada de la víctima" (→ Qué es XSS).
Defensa
Exige un token CSRF
En las acciones que cambian estado (envíos de formularios, APIs), exige un token de un solo uso, imposible de adivinar, emitido por el servidor; rechaza las solicitudes sin él. La mayoría de frameworks lo traen.
Establece cookies SameSite
Marca las cookies de sesión como SameSite=Lax (o Strict) para que no se adjunten a solicitudes originadas entre sitios. Lax es el valor por defecto moderno y ayuda mucho por sí solo.
No uses GET para cambios de estado
GET (visualizar) no debe tener efectos secundarios. Haz los cambios con POST/PUT/DELETE y pásalos por la validación de token.
Comprueba Origin / Referer
Para acciones sensibles, verifica que el Origin de la solicitud es tu propio sitio y rechaza los orígenes externos.
La opinión de este sitio: en gran parte 'resuelto', pero no te confíes
Los tokens CSRF de los frameworks más el valor por defecto SameSite=Lax del navegador han reducido enormemente el CSRF clásico. Aun así, muerde en APIs propias, configuraciones heredadas y paneles de administración que se saltaron el token. Aunque "lo dejes en manos del framework", verifica una vez por ti mismo que las rutas que cambian estado realmente ejecutan la validación del token.
Huecos comunes
Aunque conozcas el mecanismo, las implementaciones tienden a fallar en dos puntos.
- GET con efectos secundarios: si un GET de visualización cambia estado, una etiqueta de imagen o un enlace normal bastan para el CSRF. Haz los cambios de estado con POST/PUT/DELETE y pásalos por la validación de token.
- Olvidar la validación de token en algunas rutas: las APIs y las funciones de administración añadidas más tarde suelen saltarse el token. No asumas "el framework lo tiene": inventaría una vez cada ruta que cambie estado.
Sigue leyendo
- Glosario: Qué es XSS · Qué es SSRF
- Fundamentos: Fundamentos de seguridad
FAQ
Q¿En qué se diferencia CSRF de XSS?
XSS ejecuta un script en el navegador de la víctima; CSRF usa el estado con sesión iniciada de la víctima para enviar una solicitud no deseada. CSRF funciona incluso sin ejecutar ningún script: basta con que el navegador envíe las cookies automáticamente.
Q¿Cuál es la principal defensa contra CSRF?
Exigir un token CSRF en las solicitudes que cambian estado (POST, etc.) y establecer SameSite (Lax/Strict) en las cookies de sesión. La mayoría de frameworks traen el token por defecto. Además: nunca uses GET para cambios de estado.
Q¿Basta con SameSite por sí solo?
Ayuda mucho, pero no es una bala de plata. Quedan huecos en navegadores antiguos, ciertas navegaciones y algunas configuraciones de subdominios, así que combínalo con tokens CSRF para una defensa en profundidad.