Un endpoint de transferencia de fondos acepta un simple POST autenticado por cookie, sin token. ¿Qué falta?
Respuesta breve
Si el navegador adjunta automáticamente la cookie de sesión, una página maliciosa puede desencadenar la transferencia en nombre de la víctima — es Cross-Site Request Forgery (CSRF). Proteja las peticiones que cambian de estado con tokens anti-CSRF y cookies SameSite, y verifique la cabecera Origin/Referer. La cookie prueba la identidad pero no la intención, un CAPTCHA de inicio de sesión no protege una acción ya autenticada, y HTTPS protege la confidencialidad del transporte, no la falsificación de peticiones.
Un endpoint de transferencia de fondos que solo confía en la cookie de sesión es un objetivo de manual para el Cross-Site Request Forgery (CSRF). El navegador adjuntará servicialmente esa cookie a cualquier petición hacia su dominio — incluida una disparada por una página completamente ajena, controlada por el atacante, que la víctima visite por casualidad.
Cómo funciona el ataque
El atacante aloja una página con un formulario de autoenvío (o una imagen/un fetch) que hace un POST a su endpoint de transferencia con el destinatario y el importe que elija. Cuando una víctima autenticada abre esa página, su navegador envía la petición con la cookie de sesión válida, y su servidor — al ver una sesión correctamente autenticada — ejecuta la transferencia. La víctima nunca pulsó «enviar dinero». La cookie demostró quién es, pero nunca que ella quisiera esta acción.
La solución correcta
Las peticiones que cambian de estado necesitan una prueba de intención que una página externa no pueda aportar:
- Tokens anti-CSRF (patrón synchronizer-token): un valor impredecible, propio de la sesión, incrustado en el formulario y validado del lado del servidor. Un atacante cross-site no puede leerlo debido a la same-origin policy.
- Cookies SameSite (
LaxoStrict) para que la cookie de sesión, de entrada, no se envíe en peticiones cross-site — una base moderna y sólida. - Verifique la cabecera Origin/Referer en peticiones sensibles, como defensa en profundidad.
Por qué las demás respuestas son incorrectas
- «Nada — las cookies autentican al usuario» confunde la autenticación con la autorización de esta petición concreta. Esa es exactamente la brecha que explota el CSRF.
- Un CAPTCHA en la página de inicio de sesión protege el evento de login; no hace nada una vez que el usuario ya está autenticado y la petición forjada se apoya en su sesión existente.
- HTTPS protege los datos en tránsito frente a la escucha y la manipulación — no impide que un sitio malicioso haga que el navegador de la víctima envíe una petición forjada perfectamente válida y cifrada.
El entrevistador quiere ver que separa la identidad de la intención y que recurre a tokens y SameSite, no a la seguridad del transporte.
Posibles preguntas de seguimiento
- ¿En qué se diferencia SameSite=Lax de Strict, y dónde deja cada uno una brecha?
- ¿Por qué el patrón synchronizer-token es más robusto que comprobar solo el Referer?
- ¿En qué se diferenciarían las defensas CSRF entre una sesión por cookie y una API con token Bearer?