Skip to main content
HighProtected by PowerWAF

Cross-Site Request Forgery (CSRF)

CategoríaCross-SiteOWASPA01:2021 – Control de Acceso RotoPrimera aparición2001Tiempo de lectura7 minVerificado2026-03-01
DEFINICIÓN

Cross-Site Request Forgery (CSRF) es un ataque que obliga a usuarios autenticados a ejecutar acciones no deseadas en una aplicación web donde están actualmente conectados. Al elaborar una solicitud maliciosa disfrazada como legítima, un atacante puede engañar al navegador de la víctima para que realice operaciones que cambian el estado, como transferir fondos, cambiar direcciones de correo electrónico o modificar la configuración de la cuenta — todo sin el conocimiento del usuario.

Cómo Funciona Cross-Site Request Forgery (CSRF)

CSRF explota la confianza que una aplicación web tiene en el navegador del usuario. Cuando un usuario está autenticado, el navegador adjunta automáticamente las cookies de sesión a cada solicitud enviada a ese dominio — incluyendo solicitudes iniciadas por sitios maliciosos de terceros.

1

La víctima se autentica en el sitio objetivo

El usuario inicia sesión en una aplicación web (ej., su banco) y recibe una cookie de sesión. El navegador almacena esta cookie y la incluye con cada solicitud posterior a ese dominio.

2

El atacante elabora una solicitud falsificada

El atacante crea una página maliciosa que contiene un formulario oculto o una etiqueta de imagen que activa una acción en el sitio objetivo — por ejemplo, una transferencia de fondos: <img src='https://bank.com/transfer?to=attacker&amount=10000'>.

3

La víctima visita la página maliciosa

A través de phishing, ingeniería social o un sitio comprometido, la víctima visita la página del atacante mientras aún está autenticada en la aplicación objetivo.

4

El navegador ejecuta la solicitud falsificada

El navegador de la víctima adjunta automáticamente la cookie de sesión válida y envía la solicitud al sitio objetivo. El servidor no puede distinguirla de una acción legítima del usuario y la procesa.

Ejemplos Reales

2006

CSRF en Netflix (toma de control de cuentas)

Una vulnerabilidad CSRF permitió a los atacantes cambiar los detalles de las cuentas de Netflix, añadir DVDs a la cola de alquiler y cambiar la dirección de envío — todo engañando a los usuarios para que visitaran una página maliciosa.

2008

CSRF en ING Direct (transferencia de fondos)

Un fallo CSRF en la banca en línea de ING Direct permitió a los atacantes iniciar transferencias de fondos desde las cuentas de los usuarios autenticados sin su consentimiento.

2022

Vulnerabilidades CSRF en WordPress

Múltiples plugins de WordPress fueron encontrados vulnerables a CSRF, permitiendo a los atacantes cambiar la configuración del sitio, crear cuentas de administrador e inyectar contenido malicioso cuando los administradores visitaban páginas manipuladas.

Impacto y Evaluación de Riesgo

CSRF puede provocar transferencias de fondos no autorizadas, cambios en la configuración de cuentas, modificaciones de correo electrónico o contraseña, escalamiento de privilegios y manipulación de datos. En contextos administrativos, CSRF puede encadenarse con otras vulnerabilidades para lograr el compromiso total del sitio. La severidad depende de las acciones que el usuario autenticado pueda realizar — el CSRF a nivel de administrador es particularmente devastador.

Cómo Detectar Cross-Site Request Forgery (CSRF)

Revisar los logs de la aplicación en busca de solicitudes que cambian el estado originadas desde referrers inesperados. Monitorear solicitudes que carecen de tokens CSRF o con tokens no coincidentes. Implementar análisis de cookies SameSite para detectar patrones de solicitudes cross-origin. Usar reglas de WAF para detectar solicitudes GET que cambian el estado (un vector CSRF común). Probar con escáneres automatizados que verifican la ausencia de protecciones anti-CSRF en formularios.

Cómo Prevenir Cross-Site Request Forgery (CSRF)

Implementar tokens anti-CSRF (patrón de token sincronizador) en todos los formularios y solicitudes AJAX que cambian el estado. Configurar el atributo SameSite en las cookies de sesión a 'Lax' o 'Strict' para prevenir la inclusión de cookies cross-origin. Verificar los encabezados Origin y Referer en las solicitudes que cambian el estado. Requerir re-autenticación para operaciones sensibles (ej., cambios de contraseña, transferencias de fondos). Nunca usar solicitudes GET para operaciones que cambian el estado. Usar el patrón Double Submit Cookie como capa adicional.

Ejemplos de Código

CSRF Attack Example (Malicious Page)
<!-- Attacker's page: auto-submitting hidden form -->
<html>
<body onload="document.forms[0].submit()">
<form action="https://bank.com/transfer" method="POST">
<input type="hidden" name="to" value="attacker-account">
<input type="hidden" name="amount" value="10000">
</form>
</body>
</html>
Secure: CSRF Token Implementation (Express.js)
import csrf from 'csurf';

const csrfProtection = csrf({ cookie: { sameSite: 'strict' } });

// Generate token for forms
app.get('/transfer', csrfProtection, (req, res) => {
res.render('transfer', { csrfToken: req.csrfToken() });
});

// Validate token on submission
app.post('/transfer', csrfProtection, (req, res) => {
// Token is automatically validated by the middleware
processTransfer(req.body);
});

PowerWAF bloquea automáticamente Cross-Site Request Forgery (CSRF) antes de que llegue a tu servidor.

Implementa en minutos. Sin cambios de código. Plan gratuito disponible.

Los cupos del plan gratuito son limitados

Preguntas Frecuentes

XSS explota la confianza que un usuario tiene en un sitio web inyectando scripts maliciosos que se ejecutan en el navegador del usuario. CSRF explota la confianza que un sitio web tiene en el navegador del usuario falsificando solicitudes que llevan las credenciales válidas del usuario. XSS lee datos; CSRF realiza acciones.
SameSite=Lax previene que las cookies se envíen en solicitudes POST cross-site y en la mayoría de las navegaciones cross-site, bloqueando la mayoría de los ataques CSRF. SameSite=Strict proporciona la protección más fuerte pero puede interferir con flujos legítimos de navegación cross-site. Los navegadores modernos usan SameSite=Lax por defecto.
Sí, si la API usa autenticación basada en cookies. Las APIs que usan encabezados Authorization con tokens bearer no son vulnerables a CSRF porque el navegador no adjunta automáticamente encabezados personalizados a solicitudes cross-origin.