Tema 7
CSRF ocurre cuando un atacante induce al navegador de un usuario autenticado a enviar una solicitud válida a una aplicación, aprovechando que el navegador adjunta automáticamente credenciales como cookies o sesiones. El sitio confía en la solicitud, pero no en la intención real del usuario.
Una aplicación web suele identificar al usuario mediante cookies o sesiones que el navegador envía automáticamente en cada solicitud al dominio correspondiente. Esa automatización mejora la experiencia, porque el usuario no necesita autenticarse en cada clic. Pero también crea una posibilidad peligrosa: si otro sitio logra hacer que el navegador de la víctima envíe una solicitud al sitio autenticado, las credenciales viajarán con ella.
Si la aplicación no verifica si esa acción fue iniciada intencionalmente por el usuario, puede aceptar operaciones que nunca quiso realizar. Allí aparece CSRF.
La idea clave es que el navegador no está comprometido ni la sesión necesariamente robada. El problema es que el sitio no distingue una solicitud legítima de una solicitud inducida desde otro origen.
Cross-Site Request Forgery, o falsificación de solicitudes entre sitios, es un ataque donde el navegador de una víctima autenticada ejecuta una acción no deseada contra una aplicación en la que ya tiene una sesión activa.
Para que esto ocurra, normalmente se combinan varias condiciones:
Estas dos vulnerabilidades suelen aparecer cerca en el temario porque ambas involucran al navegador, pero su lógica es distinta.
XSS compromete la ejecución dentro del navegador. CSRF compromete la confianza de la aplicación en solicitudes que parecen legítimas por venir con una sesión válida.
Un ejemplo clásico ayuda a visualizarlo. Supongamos que un usuario está autenticado en un sistema bancario. Luego visita otro sitio controlado por un atacante. Ese sitio incluye un formulario oculto o un recurso que dispara una solicitud hacia la aplicación bancaria. Como el navegador ya tiene la cookie de sesión del banco, la envía automáticamente junto con la petición.
Si el banco acepta la operación solo porque la solicitud trae una sesión válida, podría ejecutar una transferencia, un cambio de email o cualquier acción sensible que no exija confirmación adicional.
CSRF es especialmente relevante en operaciones que cambian estado. Algunos ejemplos típicos:
Cuanto más sensible sea la acción, mayor debería ser el nivel de verificación de intención.
Una aplicación suele ser vulnerable a CSRF cuando depende exclusivamente de credenciales enviadas automáticamente por el navegador, como cookies de sesión, y no implementa una prueba adicional que confirme que la solicitud proviene del flujo legítimo.
Esto suele ocurrir en aplicaciones tradicionales basadas en sesión, especialmente cuando:
Por convención, `GET` debería utilizarse para obtener información sin cambiar estado, mientras que `POST`, `PUT`, `PATCH` y `DELETE` se usan para operaciones con efecto sobre el sistema. Desde la seguridad, esta distinción importa mucho.
Si una aplicación permite acciones sensibles mediante `GET`, se expone más fácilmente a CSRF y a otros problemas como caché indebida o activación accidental. Aunque usar `POST` no resuelve CSRF por sí solo, sí ayuda a mantener una semántica correcta y a aplicar defensas específicas donde corresponde.
La defensa clásica contra CSRF es incluir un token impredecible asociado a la sesión o al formulario y exigir que ese valor viaje en la solicitud de cambio de estado. Como el atacante no debería poder conocer ni generar ese token válido, le resulta mucho más difícil falsificar la petición.
La idea central del token es agregar una prueba de intención o de origen legítimo que no dependa solo de la cookie enviada automáticamente.
Este token suele:
Existen distintos patrones de implementación. Uno conocido es el de doble envío, donde el valor del token viaja en una cookie y también en otro canal como un campo o header, y el servidor comprueba coincidencia. La idea general sigue siendo la misma: la solicitud debe traer algo más que la cookie de sesión automática.
La elección concreta depende de la arquitectura del sistema, del framework usado y del modelo de autenticación.
El atributo `SameSite` en cookies ayuda a limitar cuándo el navegador enviará una cookie en solicitudes iniciadas desde otros sitios. Es una medida muy útil para mitigar ciertos escenarios de CSRF.
De forma simplificada:
`SameSite` es una capa importante, pero no siempre debe considerarse la única defensa, sobre todo en aplicaciones complejas o acciones muy sensibles.
Otra defensa complementaria consiste en revisar cabeceras como `Origin` o `Referer` para confirmar que la solicitud proviene del sitio esperado. Si la petición sensible llega desde un origen diferente, puede rechazarse.
Estas verificaciones pueden ser útiles, pero deben aplicarse con criterio y comprender sus limitaciones operativas. No reemplazan por sí solas a un diseño sólido de protección.
Para acciones especialmente críticas, como cambiar contraseña, transferir dinero, desactivar MFA o borrar una cuenta, conviene pedir una prueba adicional de intención. Esto puede ser reingresar contraseña, confirmar con un segundo factor o atravesar un flujo explícito de validación.
Estas medidas no solo reducen CSRF, sino también otros abusos de sesión o acciones disparadas por error.
No todas las arquitecturas tienen el mismo nivel de exposición a CSRF. Si una API usa tokens enviados manualmente en cabeceras y no depende de cookies automáticas del navegador, el escenario cambia. En cambio, cuando la autenticación sí se apoya en cookies de sesión o el frontend usa el navegador como transporte automático de credenciales, CSRF vuelve a ser relevante.
La pregunta práctica es: ¿el navegador adjunta automáticamente la credencial en una solicitud iniciada desde otro sitio? Si la respuesta es sí, hay que pensar seriamente en CSRF.
Imaginemos un portal donde el usuario autenticado puede cambiar el correo de recuperación con un formulario simple. Si el sitio solo revisa que la sesión sea válida, un atacante podría lograr que la víctima visite una página maliciosa que dispare esa solicitud con otro email. La aplicación vería una petición autenticada y ejecutaría el cambio.
Si en cambio la operación exige un token anti-CSRF válido y la cookie se configura con `SameSite`, el ataque se vuelve mucho más difícil o directamente falla.
CSRF se conecta con varios temas del curso:
Una estrategia madura suele combinar varias capas:
CSRF muestra un problema clásico de confianza en aplicaciones web: asumir que una solicitud autenticada necesariamente expresa la voluntad del usuario. En realidad, el navegador puede ser inducido a enviarla desde otro contexto si la aplicación no exige pruebas adicionales de intención.
En el próximo tema avanzaremos hacia otro bloque crítico del curso: autenticación segura, gestión de contraseñas y MFA.