Imagina que haces clic en un enlace que parece inofensivo y, sin enterarte de nada, acabas de cambiar la contraseña de una de tus cuentas. No has rellenado ningún formulario ni has confirmado nada: simplemente has pinchado. Eso, en esencia, es un ataque CSRF, una de las vulnerabilidades web más curiosas porque aprovecha algo que usas todos los días: tu sesión abierta en una web de confianza.
En este artículo te explicamos qué es un ataque CSRF con palabras sencillas, cómo consigue colarse un atacante y, sobre todo, qué medidas reales lo frenan. También aclararemos algunas ideas que circulan sobre este tema y que no son del todo exactas, para que te quedes con la foto correcta.
Qué significa CSRF y por qué importa
CSRF son las siglas de Cross-Site Request Forgery, que se traduce como «falsificación de peticiones entre sitios», según recoge la Wikipedia. El nombre es técnico, pero la idea es fácil: un sitio malicioso logra que tu navegador envíe una orden a otra web distinta, en la que tú tienes la sesión iniciada, para que se ejecute una acción que tú no has querido hacer.
La clave está en cómo funcionan las sesiones. Cuando entras en una web y escribes tu usuario y contraseña, el sitio no te pide las credenciales en cada clic. En su lugar, guarda en tu navegador un pequeño identificador llamado cookie. Es como la pulsera de un festival: una vez te la ponen en la entrada, pasas por cualquier zona sin tener que mostrar la entrada otra vez. El problema es que tu navegador envía esa «pulsera» de forma automática con cada petición que hace a esa web, venga de donde venga el clic.
Según la documentación sobre CSRF de GeeksforGeeks, el ataque se basa precisamente en eso: el navegador adjunta la cookie de sesión sin preguntar, así que si un atacante consigue que tu navegador envíe una orden, esa orden llegará con tu identidad puesta. Interesa a cualquiera, no solo a los informáticos, porque la víctima no tiene que introducir datos ni cometer ningún error evidente: basta un clic.
Cómo se cuela el atacante paso a paso
Veamos el ejemplo más citado: un formulario para cambiar la contraseña. En un diseño vulnerable, ese formulario solo pide la nueva contraseña (dos veces para confirmar) y no vuelve a pedir la contraseña actual. Al pulsar «guardar», tu navegador envía la nueva contraseña junto con tu cookie de sesión, y la web da por buena la orden.
Aquí conviene hacer una aclaración. A veces se presenta este formulario «flojo» como el caso habitual, pero no lo es: es un ejemplo de mal diseño. La guía de pruebas de seguridad de OWASP recomienda pedir de nuevo la contraseña actual al cambiarla, precisamente para proteger una sesión que alguien haya podido dejar abierta. Es decir, el fallo existe cuando el desarrollador no toma esa precaución, no porque sea lo normal.
El segundo ingrediente es el tipo de petición. En la web existen dos formas básicas de comunicarse: las peticiones GET, pensadas para pedir y leer datos (como cuando escribes una dirección en el navegador), y las POST, pensadas para enviar datos, como al mandar un formulario. Las acciones que modifican algo deberían usar POST. Si una web permite, por error, cambiar la contraseña mediante una simple GET, entonces los datos del cambio se pueden meter directamente en una dirección web. Y una dirección web es muy fácil de compartir: basta con un enlace.
OWASP advierte en su guía de prevención de CSRF de que usar GET para acciones que cambian datos es un riesgo, y recomienda reservar GET solo para leer. Que esto no es teórico lo demuestra un caso documentado por el investigador Sjoerd Langkemper, que describió un cambio de contraseña mediante CSRF en un programa de recursos humanos. Así que la afirmación de que «enviando los datos por GET la contraseña cambia sin confirmación» es cierta, pero con un matiz importante: solo ocurre si la aplicación acepta ese cambio por GET.
Del experimento al ataque real
Una vez el atacante tiene un enlace que ejecuta la acción, necesita que la víctima haga clic. Para ello recurre a la ingeniería social, que no es más que el arte de engañar a una persona para que haga algo. El enlace se puede disfrazar con un acortador de direcciones o esconder detrás de un texto con apariencia legítima dentro de un correo, como describe la guía sobre CSRF de Graylog. Cuando la víctima pincha, su propio navegador envía la petición con su cookie de sesión, y la acción se ejecuta con su identidad.
Sobre este punto circula una idea que conviene matizar. Se dice a veces que, como el atacante «ya conoce el nombre de usuario», le basta con iniciar sesión luego con la nueva contraseña. En la práctica no es tan automático: el CSRF no revela quién es la víctima, el atacante necesita saber de antemano a qué cuenta dirige el ataque y no todos los sitios permiten entrar solo con el nombre de usuario. No hemos encontrado una fuente que describa ese paso como una regla general, así que es mejor tomarlo como un escenario posible, no como algo que ocurra siempre.
Que el riesgo es real lo confirma la historia. Según la Wikipedia, las vulnerabilidades CSRF se conocen y, en algunos casos, se han explotado desde 2001. La misma fuente recuerda que en 2008 una plataforma de vídeos muy popular tuvo un fallo CSRF que permitía realizar casi cualquier acción en nombre de cualquier usuario. No es un problema de laboratorio.
Las defensas que de verdad funcionan
La buena noticia es que el CSRF tiene remedios conocidos. Se suelen citar tres medidas, y conviene explicarlas bien porque a veces se presentan como una solución que lo corta «de raíz», algo que es exagerado. OWASP insiste en la idea de defensa en profundidad: combinar varias barreras, porque ninguna por sí sola es infalible.
Token CSRF único por formulario
Un token CSRF es un valor secreto y aleatorio que la web incluye en cada uno de sus formularios y que solo su propia página conoce. Cuando llega una petición, el servidor comprueba que trae ese valor. Un sitio ajeno no puede adivinarlo, así que no puede falsificar la orden. OWASP lo sitúa como la defensa principal frente al CSRF.
Cookies con el atributo SameSite
El atributo SameSite es una instrucción que le dice al navegador cuándo debe enviar una cookie si la petición viene desde otro sitio. Desde 2020, tanto Mozilla como Google aplican el valor Lax por defecto, como explica Mozilla Hacks. Esto ayuda, pero tiene un límite importante: con Lax, el navegador sigue enviando la cookie cuando sigues un enlace mediante una petición GET, según la documentación de MDN. Por eso OWASP advierte de que, si una acción que cambia datos es accesible por GET, SameSite no la detendrá. Es decir, SameSite es un refuerzo, no un escudo completo.
Pedir siempre la contraseña actual
Para la acción concreta de cambiar la contraseña, pedir de nuevo la contraseña actual es una barrera sencilla y eficaz, tal como recomienda OWASP. Un atacante que solo ha conseguido que hagas clic en un enlace no conoce tu contraseña actual, así que la petición falsificada no supera esa comprobación.
A todo esto se suma un recordatorio: existe otro tipo de fallo llamado XSS (cross-site scripting), en el que el atacante logra insertar código en la propia web legítima. Si ese fallo existe, puede saltarse las defensas CSRF. Por eso no basta con una sola medida.
¿Y a mí en qué me afecta?
Como usuario normal no programas webs, pero sí puedes reducir el riesgo con hábitos sencillos:
- Desconfía de los enlaces que llegan por correo o mensajería, sobre todo si están acortados o te empujan a pinchar con urgencia. Pasar el ratón por encima para ver la dirección real ayuda.
- Cierra sesión en los servicios sensibles (banca, correo, administración) cuando termines, en lugar de dejarlos siempre abiertos.
- Usa navegadores actualizados, que ya aplican SameSite por defecto y te protegen en parte sin que hagas nada.
- Activa la verificación en dos pasos donde sea posible: añade una barrera extra aunque una contraseña quede comprometida.
Y si tienes o gestionas una web, las recomendaciones del dossier son claras: usa POST (no GET) para cualquier acción que modifique datos, incorpora tokens CSRF en los formularios, configura las cookies con SameSite y pide la contraseña actual al cambiarla.
En resumen
Un ataque CSRF aprovecha que tu navegador envía automáticamente tu sesión para ejecutar, con tu identidad, una acción que tú no has pedido, muchas veces con un simple clic en un enlace disfrazado. Es un riesgo real y antiguo, pero con defensas bien conocidas: tokens únicos por formulario, cookies con SameSite y pedir la contraseña actual en los cambios sensibles. Ninguna de esas medidas lo resuelve por sí sola, pero combinadas convierten un ataque cómodo en uno muy difícil. Para ti, la mejor protección sigue siendo pensar dos veces antes de hacer clic.
