Imagina que estás tranquilamente navegando por internet, quizás mirando memes de gatos o comparando precios de botifarra, y mientras tanto alguien ejecuta una transferencia bancaria desde tu cuenta. Sin malware, sin robarte la contraseña, sin phishing. Bienvenido al maravilloso mundo del CSRF o Cross Site Request Forgery, uno de los ataques más elegantemente traicioneros que existen. La falsificación de petición entre sitios —que es como lo traducimos los que nos gusta sufrir— permite que un atacante ejecute acciones en tu nombre aprovechando que ya tienes una sesión abierta en otro sitio. Un ataque CSRF no necesita conocer tu contraseña: solo necesita que estés logueado. Y sí, el token CSRF existe precisamente para evitar esta fiesta, pero ya llegaremos a eso.
Qué es exactamente un ataque CSRF y por qué debería preocuparte
El Cross Site Request Forgery es un tipo de ataque en el que un sitio web malicioso hace que tu navegador envíe una petición legítima a otro sitio donde ya estás autenticado. La clave está en cómo funcionan las cookies: cuando visitas tu banco online y te logueas, el navegador almacena una cookie de sesión. A partir de ese momento, cada petición que tu navegador haga a ese dominio incluirá automáticamente esa cookie. Y aquí está el problema: al navegador le da exactamente igual si la petición la iniciaste tú haciendo clic en un botón o si la generó un formulario oculto en la web de recetas de la abuela.
El término fue acuñado formalmente alrededor de 2001, pero los ataques de este tipo llevan existiendo desde los inicios de la web. El OWASP lo ha incluido repetidamente en su Top 10 de vulnerabilidades web, y no por capricho. En 2008, un ataque CSRF afectó a millones de usuarios de Netflix, permitiendo a atacantes cambiar las direcciones de envío de DVD (sí, Netflix enviaba DVDs, esos tiempos). Ese mismo año, investigadores demostraron cómo un CSRF podía cambiar la configuración DNS de routers domésticos —CVE-2008-1244 entre otros—, redirigiendo todo el tráfico de una red doméstica a servidores maliciosos.
Para que un CSRF funcione necesitas tres ingredientes: que la víctima tenga una sesión activa en el sitio objetivo, que el sitio no implemente protecciones adecuadas (como un token CSRF), y que el atacante consiga que la víctima visite una página bajo su control. Tres condiciones que se cumplen con una frecuencia alarmante.
Cómo funciona un ataque CSRF paso a paso
Vamos a desmontarlo con un ejemplo práctico, porque la teoría está muy bien pero aquí venimos a ensuciarnos las manos (de forma ética, claro).
Supongamos que tu banco tiene un endpoint para transferencias que funciona así:
GET https://mibanco.com/transferir?destino=ES1234567890&cantidad=1000
Sí, hay bancos que han usado GET para operaciones sensibles. No me mires así, yo tampoco me lo creo. Ahora, un atacante crea una página web con este código aparentemente inocente:
Si te interesa este tema, te recomendamos leer nuestro artículo sobre Ataques adversariales a inteligencia artificial: cómo engañar a los modelos de IA, donde profundizamos en aspectos clave relacionados.
<img src="https://mibanco.com/transferir?destino=ES9999999999&cantidad=5000" width="0" height="0">
Cuando visitas esa página, tu navegador intenta cargar la "imagen" y envía la petición al banco incluyendo tu cookie de sesión. El banco recibe una petición perfectamente válida desde un usuario autenticado y ejecuta la transferencia. Tú ni te enteras.
Con formularios POST la cosa es ligeramente más elaborada pero igual de efectiva:
- El atacante crea un formulario oculto que apunta al sitio objetivo
- Usa JavaScript para enviar el formulario automáticamente al cargar la página
- El navegador envía la petición POST con todas las cookies del dominio destino
- El servidor procesa la acción como si la hubiera iniciado el usuario legítimo
Variantes más sofisticadas incluyen el login CSRF, donde el atacante te loguea en su propia cuenta para que, sin saberlo, guardes información sensible en un perfil que él controla. También existe el CSRF almacenado, donde el payload malicioso se inyecta directamente en el sitio vulnerable —por ejemplo, en un foro que permite HTML en los posts—, eliminando la necesidad de que la víctima visite un sitio externo.
Defensas reales contra la falsificación de peticiones
Ahora viene la parte constructiva. Porque quejarse está muy bien —es casi un deporte nacional en Catalunya—, pero más vale prevenir que lamentar.
Token CSRF (Synchronizer Token Pattern): Es la defensa clásica y más extendida. El servidor genera un token CSRF único, impredecible y asociado a la sesión del usuario. Este token se incluye como campo oculto en cada formulario. Cuando el servidor recibe la petición, verifica que el token coincida. Un atacante en otro dominio no puede leer este token gracias a la Same-Origin Policy, así que no puede incluirlo en su formulario malicioso. Frameworks como Django, Laravel, Rails y Spring lo implementan de serie. Si usas uno de estos frameworks y no tienes protección CSRF activa, es porque alguien la desactivó deliberadamente, y ese alguien debería replantearse sus decisiones vitales.
SameSite Cookies: A partir de Chrome 80 (febrero 2020), las cookies se envían por defecto con SameSite=Lax, lo que significa que no se incluyen en peticiones cross-site de tipo POST. Esto ha sido un antes y un después para la falsificación de petición. Sin embargo, las peticiones GET con navegación de nivel superior (como hacer clic en un enlace) sí envían las cookies, así que si tus endpoints sensibles aceptan GET... ya sabes.
Double Submit Cookie: Una alternativa al token sincronizado. El servidor envía un valor aleatorio tanto en una cookie como en un campo del formulario. Al recibir la petición, compara ambos valores. Un atacante puede hacer que el navegador envíe la cookie, pero no puede leerla para copiar el valor en el formulario. Tiene sus limitaciones —especialmente si el atacante puede escribir cookies en subdominios—, pero es una opción válida para arquitecturas stateless.
Verificación del header Origin/Referer: El servidor puede comprobar que la cabecera Origin o Referer de la petición corresponde a su propio dominio. Es una capa adicional útil, aunque no debe ser la única defensa, ya que estos headers pueden ser suprimidos por extensiones o proxies.
Si te interesa este tema, te recomendamos leer nuestro artículo sobre DNS spoofing: cuando te redirigen a webs falsas sin que te des cuenta, donde profundizamos en aspectos clave relacionados.
- Nunca uses GET para acciones que modifican estado (transferencias, cambios de contraseña, eliminaciones)
- Implementa tokens CSRF en todos los formularios, sin excepción
- Configura cookies con
SameSite=StrictoSameSite=Laxsegún tu caso de uso - Añade reautenticación para operaciones críticas (cambio de email, transferencias grandes)
- Usa headers personalizados en peticiones AJAX —los navegadores no permiten enviar headers custom en peticiones cross-origin simples—
Casos reales y lecciones que duelen
La historia del CSRF está plagada de incidentes que, vistos con perspectiva, resultan casi cómicos. Casi.
En 2006, un investigador demostró cómo un ataque CSRF podía vaciar la lista de contactos completa de Gmail. Google, que por aquel entonces todavía se estaba acostumbrando a que su webmail fuera el centro del universo digital, parcheó la vulnerabilidad rápidamente. En 2010, investigadores descubrieron que ING Direct era vulnerable a CSRF, permitiendo potencialmente transferencias no autorizadas entre cuentas —una de esas cosas que te quitan el sueño si trabajas en el sector bancario—.
Más recientemente, en 2019 se descubrió un Cross Site Request Forgery en TikTok (CVE-2020-13845 y relacionados) que permitía cambiar la contraseña de cualquier cuenta. El ataque era tan sencillo que solo requería que la víctima hiciera clic en un enlace. Plataformas como WordPress han tenido históricamente docenas de vulnerabilidades CSRF en plugins —si tienes un WordPress, ya puedes ir revisando qué plugins llevas—. Herramientas como WPScan y Burp Suite son fundamentales para detectar estos problemas antes de que lo haga alguien con peores intenciones.
La lección recurrente es siempre la misma: la falsificación de petición entre sitios aprovecha la confianza que el servidor deposita ciegamente en las cookies del navegador. Si tu aplicación web asume que "si la cookie es válida, la petición es legítima", tienes un problema. Es como asumir que cualquiera que lleve tu camiseta del Barça es amigo tuyo.
Herramientas para detectar y prevenir CSRF
Si desarrollas aplicaciones web o simplemente quieres auditar las tuyas, estas herramientas son tus mejores aliadas:
| Herramienta | Tipo | Uso principal |
|---|---|---|
| Burp Suite | Proxy de interceptación | Detectar endpoints sin protección CSRF |
| OWASP ZAP | Scanner gratuito | Escaneo automatizado de vulnerabilidades web |
| CSRFTester (OWASP) | Herramienta específica | Generar y probar payloads CSRF |
| WPScan | Scanner WordPress | Detectar plugins vulnerables a CSRF |
| Browser DevTools | Integrado | Verificar cookies SameSite y tokens |
Como usuarios, la mejor defensa es cerrar sesión en sitios sensibles cuando termines de usarlos, mantener el navegador actualizado y ser escéptico con enlaces sospechosos. Sí, lo sé, "cerrar sesión" es como pedir que la gente recoja la mesa después de comer: todo el mundo sabe que debería hacerlo, nadie lo hace.
Preguntas frecuentes
¿Cuál es la diferencia entre CSRF y XSS?
El CSRF engaña al navegador para que envíe peticiones no deseadas aprovechando la sesión activa del usuario, sin necesidad de inyectar código en el sitio objetivo. El XSS (Cross-Site Scripting) inyecta código malicioso directamente en el sitio vulnerable, que luego se ejecuta en el navegador de la víctima. En resumen: el CSRF abusa de la confianza del servidor en el usuario, mientras que el XSS abusa de la confianza del usuario en el servidor. Y ambos son una fiesta a la que no quieres ser invitado.
¿Un token CSRF es suficiente para estar protegido?
Un token CSRF bien implementado es la base de la defensa, pero no debería ser tu única protección. Lo ideal es combinarlo con cookies SameSite, verificación de headers Origin y reautenticación para operaciones críticas. La seguridad en capas no es paranoia, es sentido común. Además, asegúrate de que el token sea aleatorio, único por sesión y se valide en el servidor —suena obvio, pero te sorprendería la cantidad de implementaciones que fallan en alguno de estos puntos—.
¿Las APIs REST también son vulnerables a CSRF?
Depende. Si tu API usa cookies para autenticación (como las session cookies), sí es vulnerable a Cross Site Request Forgery. Si usa tokens Bearer en headers de autorización (como JWT), el riesgo es mucho menor, porque los headers personalizados no se envían automáticamente en peticiones cross-origin. Sin embargo, muchas aplicaciones SPA siguen usando cookies httpOnly para almacenar tokens, así que no des nada por sentado y revisa tu implementación.
¿Los navegadores modernos no han solucionado ya el problema del CSRF?
El atributo SameSite=Lax por defecto en Chrome, Edge y Firefox ha reducido enormemente la superficie de ataque CSRF, especialmente para peticiones POST cross-site. Pero no es una solución completa: las peticiones GET de navegación siguen enviando cookies, algunos navegadores antiguos no lo soportan, y existen técnicas para eludirlo en ciertas configuraciones. Confiar solo en el navegador para tu seguridad es como confiar en que el tiempo en Barcelona será predecible: una apuesta arriesgada.
¿Cómo puedo comprobar si mi sitio web es vulnerable a CSRF?
El método más directo es usar Burp Suite u OWASP ZAP para interceptar peticiones a formularios y endpoints de tu aplicación, y luego intentar reproducirlas desde un dominio diferente sin el token de protección. Si la petición se ejecuta correctamente, tienes un problema. También puedes revisar manualmente que todos tus formularios incluyan un campo de token CSRF y que tus cookies tengan configurado el atributo SameSite. Para WordPress, ejecuta WPScan y revisa los resultados con atención.
El CSRF es uno de esos ataques que parece de otra época pero que sigue acechando en aplicaciones modernas mal configuradas. La buena noticia es que las defensas son bien conocidas y relativamente fáciles de implementar. La mala noticia es que todavía hay desarrolladores que piensan que "a mí no me va a pasar". Si has llegado hasta aquí, ya vas un paso por delante. Sigue explorando nuestros artículos sobre ciberataques y recuerda: en MataSpam nos tomamos muy en serio tu seguridad digital, aunque nos lo tomemos todo con un poco de humor. Que el spam y las vulnerabilidades no te pillen con la guardia baja.
