CSRF: qué es, cómo funciona, ejemplos y defensas

Si te dedicas al desarrollo o a la seguridad web, te interesa tener muy claro qué es la falsificación de petición en sitios cruzados. CSRF (Cross-Site Request Forgery) es un tipo de ataque sigiloso que aprovecha la sesión ya iniciada de un usuario para que su navegador ejecute acciones sin su consentimiento.

Este fenómeno no es nuevo, pero sigue siendo relevante porque los navegadores adjuntan automáticamente credenciales como cookies o cabeceras a ciertas peticiones. El servidor “confía” en el usuario y procesa la solicitud, aunque la haya iniciado una página maliciosa, un iframe o un enlace camuflado.

Qué es CSRF y por qué sigue dando guerra

En pocas palabras, CSRF es cuando un sitio A induce al navegador de un usuario autenticado a enviar una petición a un sitio B en el que ese usuario ya está logueado, de forma que B procesa la operación como válida. La clave es la confianza del sitio en el usuario, no la confianza del usuario en el sitio.

A diferencia de XSS, que explota la confianza del usuario en una página para inyectar y ejecutar código en su contexto, CSRF abusa de que el servidor da por buena cualquier solicitud que llega acompañada de credenciales válidas (p. ej., cookies de sesión). Ambos problemas se pueden combinar y empeorar el impacto.

Un poco de historia y dificultades forenses

Las vulnerabilidades de este tipo se conocen desde finales de los 90, y el término CSRF/XSRF fue acuñado por Peter Watkins en 2001. La traza del ataque suele apuntar a la IP legítima del usuario, lo que complica atribuir responsabilidades y requiere análisis forense especializado.

Durante años hubo pocos exploits públicos bien documentados, pero el problema ha sido recurrente y ha aparecido en múltiples ocasiones en el Top 10 de OWASP por su impacto y frecuencia.

Cómo funciona el ataque (condiciones y flujo)

Para que CSRF prospere se dan varias condiciones. El usuario mantiene una sesión iniciada en la aplicación objetivo; el navegador adjunta automáticamente cookies, credenciales básicas/digest o contexto de autenticación en las peticiones; y la aplicación acepta cambios de estado sin un mecanismo de verificación adicional.

El atacante convence a la víctima, mediante ingeniería social (un correo, un chat o una web atractiva), para cargar una página que dispara la petición maliciosa hacia el sitio vulnerable. El usuario puede no hacer nada más que visitar la página: un formulario autoenviado, una imagen incrustada o un iframe bastan para activar la solicitud.

Vectores típicos: GET, POST e incluso “almacenados”

Hay aplicaciones que desafortunadamente cambian estado con GET. En ese caso, un simple <img src=»URL-peligrosa» /> en una página ajena realiza la acción al cargar la imagen. Por eso, como principio básico, un GET no debería modificar recursos.

Con POST, el vector habitual es un formulario HTML camuflado que se autoenvía con JavaScript, o que el usuario envía pensando que es otra cosa. El navegador adjunta la cookie de sesión del dominio legítimo y el servidor procesa el cambio (transferir dinero, borrar un registro, cambiar un email, etc.).

En ocasiones el código de ataque puede insertarse dentro del propio sitio víctima (por fallos adicionales), alojándolo en etiquetas IMG o iframe. Este “CSRF almacenado” reduce sospechas porque la interacción parece permanecer dentro del dominio de confianza.

Impacto real en cuentas y sistemas

Las consecuencias abarcan desde operaciones financieras no autorizadas hasta cambios de configuración, reasignación de permisos o eliminación de datos. Si la víctima tiene rol de administrador, el atacante puede alterar la lógica de la aplicación o habilitar puertas traseras que afecten a más usuarios.

Incluso acciones aparentemente menores, como modificar la dirección de correo del perfil, pueden bloquear la recuperación de la cuenta o facilitar fraudes posteriores. El gran problema es que todo ocurre “en nombre del usuario” y a menudo sin que se percate.

Ejemplos concretos (y muy habituales)

Imagina un panel de administración que permite borrar un usuario con GET mediante una URL del estilo /usuarios/eliminar/63. Si un administrador autenticado visita una página de un tercero que incluye un <img src=»https://sitio-admin/usuarios/eliminar/63″ />, el navegador hará la petición y la cuenta desaparecerá.

Otro clásico: banca online. Si una transferencia se puede orquestar con GET—por ejemplo, /transfer?amount=500&account=XXXX—basta con un enlace “inocente” para que un usuario, estando logueado, dispare el envío de dinero a la cuenta del atacante.

Con POST el patrón es similar: un formulario oculto con campos “amount” y “account” se autoenvía al cargar la página. la cookie de sesión del banco del dominio legítimo y el servidor procesa la transferencia.

Factores del navegador y del protocolo

Usar HTTPS no evita el ataque por sí mismo: un sitio malicioso puede dirigir al navegador a hacer una petición segura sin problema. La autenticación básica y Digest también son vulnerables: una vez que el usuario se ha autenticado, el navegador reenvía credenciales automáticamente hasta que termina la sesión.

Las políticas de cookies SameSite ayudan, pero hay matices. Con SameSite=Strict, el navegador no enviará la cookie en contextos entre sitios y se corta de raíz gran parte de CSRF. Con SameSite=None (y Secure), en cambio, la cookie viaja entre sitios y aumenta la superficie de ataque.

Buenas prácticas para personas usuarias

Aunque el problema es fundamentalmente de la aplicación, hay hábitos que reducen el riesgo. Cerrar sesión al terminar, borrar cookies de vez en cuando, y evitar la opción “mantener la sesión abierta” minimizan ventanas de exposición.

También ayuda separar tareas: usar un navegador para gestiones sensibles y otro para la navegación general, o tirar del modo incógnito para no persistir credenciales. Extensiones que bloqueen scripts limitan automatismos (aunque no son una solución total).

Medidas de defensa en aplicaciones

Primera regla de oro: no cambiar estado con GET. Reservar POST/PUT/DELETE para operaciones que modifiquen recursos reduce vectores triviales como imágenes o enlaces encubiertos.

El enfoque más extendido para mitigar CSRF es el patrón del token sincronizador: el servidor emite un token único y aleatorio ligado a la identidad del usuario y el cliente lo devuelve en la siguiente petición que cambia estado. Si el token no cuadra con la identidad y la cookie, se rechaza la solicitud.

Otra capa útil es validar los orígenes: comprobar cabeceras Origin/Referer cuando existan. Si la petición no proviene del dominio esperado, se bloquea el procesamiento. Ojo: algunos clientes ocultan el Referer por política de privacidad, así que hay que implementar esta verificación con cabeza.

Los WAF también ayudan. Soluciones empresariales, como F5 BIG‑IP ASM o servicios de protección integrados en plataformas de hosting, añaden reglas para identificar y frenar patrones sospechosos antes de que lleguen a tu app.

Límites y errores frecuentes con tokens

Los tokens protegen si se implementan bien. Si la aplicación “pasa por alto” la verificación cuando falta el token, el atacante solo tiene que enviarlo vacío. Igualmente peligroso es usar un pool reutilizable en vez de un token por usuario: basta con robar uno válido para suplantar sesiones ajenas.

Guardar el token en una cookie accesible por JavaScript también es mala idea si no hay contrapesos: un XSS podría leerlo y reusarlo. La robustez viene de combinar cookie de sesión + token en formulario o cabecera separada, y de validar ambos.

Relación con SPA, tokens y XSS

En aplicaciones con autenticación basada en tokens (por ejemplo, JWT), enviar el token en la cabecera Authorization como Bearer y no en una cookie reduce el riesgo de CSRF, porque el navegador no lo adjunta automáticamente. Aun así, si hay XSS, un atacante podría robarlo del almacenamiento local.

Por eso, además de CSRF, hay que blindar la salida del servidor, evitar renderizar HTML sin escapado y aplicar CSP. CSRF y XSS se potencian mutuamente si dejas huecos por ambos lados.

CSRF en ASP.NET Core: lo esencial para desarrolladores

ASP.NET Core trae mitigaciones de serie. Los formularios con method=»post» pueden incluir automáticamente tokens antifalsificación en vistas de Razor (TagHelpers y helpers como BeginForm lo insertan por defecto). También puedes inyectarlos explícitamente y validar en el servidor con filtros.

La validación se activa con atributos como ValidateAntiForgeryToken o, más cómodo, AutoValidateAntiforgeryToken, que exige token en métodos no seguros (POST/PUT/DELETE) y evita exigirlo en GET/HEAD/OPTIONS/TRACE. Si necesitas excepciones, IgnoreAntiforgeryToken anula la exigencia en acciones concretas.

Para APIs y SPA, el servicio IAntiforgery permite generar y almacenar tokens, y recibirlos en una cabecera personalizada (por ejemplo, X‑XSRF‑TOKEN). Frameworks como Angular leen por convención una cookie “XSRF‑TOKEN” y envían su valor en esa cabecera, que el servidor debe validar.

Las Minimal APIs pueden validar de forma explícita el token (desde middleware o filtros de endpoint) y conviene que el middleware de antifalsificación se ejecute tras autenticación y autorización, evitando lecturas innecesarias del cuerpo de la petición si no procede.

Configuración fina: AntiforgeryOptions permite personalizar el nombre del campo oculto, el encabezado esperado, y si se emite el encabezado X‑Frame‑Options (SAMEORIGIN por defecto). En desarrollo se relaja a veces la marca Secure de la cookie; en entornos reales, se recomienda forzar HTTPS.

Ten en cuenta que con el patrón de token sincronizador, abrir varias pestañas y avanzar por flujos distintos puede invalidar tokens anteriores: solo la página más reciente tiende a tener el token válido. Plantea alternativas si tu UX depende de múltiples pestañas concurrentes.

Otro frente a vigilar es el hosting compartido bajo el mismo dominio o subdominio. Compartir *.dominio.com puede permitir que una app interfiera con cookies de otra, así que separar aplicaciones por dominios distintos aumenta el aislamiento.

Por último, la autenticación de Windows (NTLM/Kerberos) no te exime: el navegador envía el contexto de autenticación de forma implícita y, sin tokens o verificaciones de origen, también puede haber CSRF.

CDN, cargas cruzadas y por qué hay que ser cuidadosos

Es habitual que un sitio pida contenidos a terceros (vídeos de YouTube, librerías de una CDN, etc.). Si no se controla bien ese intercambio, un atacante puede aprovechar rutas entre sitios para forzar peticiones que el navegador completará con credenciales adjuntas.

Además de políticas de cookies estrictas, revisa el uso de iframes y objetos embebidos, aplica SRI cuando tires de CDNs y limita orígenes aceptados con CSP y CORS bien definidos.

Buenas prácticas extra para equipos

Establece revisiones de seguridad en cambios de formularios y endpoints que modifican estado. Automatiza tests que verifiquen la presencia y validación correcta del token, y marca como “bloqueante” cualquier regresión que reintroduzca GET con efectos laterales.

Instrumenta logging para detectar patrones raros (p. ej., envíos de formularios sin token, o con cabeceras de origen inesperadas) y apoya con un WAF que reduzca ruido y bloquee firmas conocidas de explotación.

Recordatorio clave: qué no soluciona CSRF por sí solo

El token antifalsificación no arregla la inyección de scripts; tampoco sustituye controles de autorización. Primero verifica que el usuario puede hacer la acción, luego valida el token y, si procede, comprueba Origin/Referer. Defensa en profundidad ante todo.

Y no olvides comunicar el “por qué” al equipo de producto: evitar GET que cambian estado o exigir un token adicional en ciertas operaciones no es capricho técnico, es protección directa del negocio frente a fraudes y manipulación.

Lo que hace peligroso a CSRF es su discreción: las peticiones salen del navegador de la víctima, con sus credenciales y “buena pinta”. Combinando tokens bien implementados, validación de orígenes, políticas de cookies adecuadas, diseño REST responsable y, cuando encaje, protección con WAF, se reduce drásticamente la ventana de ataque sin sacrificar experiencia de usuario.