¿Qué es el CSRF y cómo lo detienen los tokens y SameSite?
Respuesta breve
El CSRF engaña al navegador de un usuario autenticado para que envíe una petición que cambia el estado a un sitio donde está autenticado, abusando del hecho de que las cookies se envían automáticamente. Se detiene con tokens anti-CSRF (un valor secreto por sesión que el atacante no puede leer ni adivinar) y el atributo de cookie SameSite, que impide que las cookies acompañen a las peticiones de sitios cruzados.
La falsificación de petición en sitios cruzados (CSRF) explota una peculiaridad de la web: los navegadores adjuntan automáticamente las cookies de un sitio a cada petición a ese sitio, incluidas las peticiones desencadenadas por un sitio diferente. Si un usuario ha iniciado sesión en su banco y luego visita la página de un atacante, esa página puede disparar silenciosamente un envío de formulario al banco — y el navegador incluye obedientemente la cookie de sesión. El banco ve una petición autenticada y procesa la transferencia. El atacante nunca lee ninguna respuesta; solo necesita que la acción ocurra.
Por qué la autoridad ambiental es la causa raíz
El CSRF funciona porque la autenticación es ambiental — probada por una cookie que el navegador envía por su cuenta, sin prueba alguna de que la petición se haya originado realmente en la aplicación legítima. Por eso las defensas deben añadir una señal de que esta petición realmente vino de nuestra aplicación.
Tokens anti-CSRF (patrón sincronizador)
El servidor incrusta un token secreto, por sesión e impredecible en sus propios formularios y lo exige de vuelta en cada petición que cambia el estado. La página de sitio cruzado de un atacante no puede leer este token (la Same-Origin Policy bloquea la lectura de la respuesta que lo contiene) y no puede adivinarlo. Por tanto, la petición falsificada carece de un token válido y se rechaza.
Cookies SameSite
El atributo de cookie SameSite indica al navegador cuándo enviar la cookie:
- Strict — nunca en peticiones de sitios cruzados (la más fuerte, pero puede romper enlaces entrantes a páginas autenticadas).
- Lax — se envía en navegaciones de nivel superior (al hacer clic en un enlace) pero no en POST de sitios cruzados ni en peticiones de subrecursos; un valor por defecto sensato que bloquea el CSRF clásico por envío de formulario.
- None — siempre se envía (requiere
Secure); necesario para contextos legítimos de sitios cruzados.
La interacción con el XSS
Los tokens CSRF asumen que el atacante está fuera del sitio. Si la aplicación también tiene XSS, el script inyectado se ejecuta en el origen y puede leer el token — por lo que el XSS derrota la protección CSRF. Ambos deben corregirse.
Los entrevistadores buscan «envío automático de cookies» como causa raíz, la imprevisibilidad del token ligada a la Same-Origin Policy, la distinción Lax-vs-Strict y la advertencia sobre el XSS.
Posibles preguntas de seguimiento
- ¿Por qué falla la página CSRF de un atacante cuando se requiere un token sincronizador?
- ¿Cuál es la diferencia entre SameSite=Lax y SameSite=Strict?
- ¿Por qué la protección CSRF no ayuda si el sitio también tiene XSS?