Cross Site Request Forgery (CSRF, tambien XSRF o Session Riding) es un ataque web que obliga a un usuario autenticado a ejecutar una accion no deseada en una aplicacion donde tiene sesion abierta. El atacante prepara un enlace malicioso, una imagen o un formulario en un sitio que controla. Cuando la victima visita esa pagina sin haber cerrado sesion en el sitio objetivo (banca online, panel de WordPress, webmail), el navegador envia la peticion automaticamente con la cookie de sesion valida. El servidor objetivo no puede distinguir la peticion falsa de una real y la ejecuta: transferir dinero, cambiar email, borrar un post, dar permisos de admin. CSRF estuvo en el puesto 5 del OWASP Top 10 en 2007 y 2010, salio del Top 10 en 2017 porque los frameworks principales incluyeron defensas, y figura en el OWASP Top 10 2021 dentro de A01 Broken Access Control. El gusano Samy en MySpace (octubre 2005, mas de 1 millon de perfiles infectados en 20 horas) es el caso historico mas famoso de CSRF.
Como funciona un ataque CSRF?
- La victima esta autenticada en el sitio objetivo.
- El sitio objetivo ejecuta acciones que cambian estado solo en base a cookies, sin token anti CSRF.
- La victima visita una pagina controlada por el atacante o abre un email malicioso.
Ejemplo: https://banco.example.com/transferir?a=CUENTA&importe=1000 como GET. El atacante incluye:
<img src="https://banco.example.com/transferir?a=ATACANTE&importe=10000" width="0" height="0">El navegador carga la imagen con la cookie del usuario y el banco ejecuta la transferencia. La variante POST usa un formulario oculto con auto submit en JavaScript.
Objetivos tipicos de CSRF
- Banca y pagos.
- Webmail (reglas de reenvio).
- Paneles de admin (crear admin, instalar plugin).
- Redes sociales (gusano Samy).
- E-commerce (cambiar direccion de envio).
- Routers y IoT.
Diferencia CSRF vs XSS
| Propiedad | CSRF | XSS |
|---|---|---|
| Que hace | Obliga al navegador a enviar peticion | Ejecuta JavaScript del atacante |
| Codigo en el objetivo | No | Si |
| Lee la respuesta | No (Same Origin Policy) | Si |
| Burla tokens CSRF | No | Si |
| Defensa principal | Tokens, SameSite | Output encoding, CSP |
XSS es estrictamente mas potente: con XSS se lee el token del DOM. Por eso prevenir XSS es prerrequisito.
Defensas estandar contra CSRF
- Token anti CSRF (synchronizer token): defensa primaria recomendada por OWASP.
- SameSite cookie:
Strict,Lax(default Chrome desde febrero 2020),None. - Double submit cookie.
- Verificar Origin y Referer.
- Cabecera personalizada para AJAX como
X-Requested-With. - Reautenticacion para acciones criticas.
- Usar POST en lugar de GET para cambios de estado.
SameSite=Lax
Chrome lo aplica por defecto desde febrero 2020 (Chrome 80), Firefox desde agosto 2020 (Firefox 79), Safari desde 2018 con ITP. Esta sola medida del navegador neutralizo la mayoria de los CSRF clasicos.
Como protege WordPress?
WordPress usa Nonces. Funciones principales:
wp_nonce_field('accion', '_wpnonce');
$url = wp_nonce_url($url, 'accion');
$nonce = wp_create_nonce('accion');
check_admin_referer('accion');
check_ajax_referer('accion', 'nonce');Vida de 24 horas (dos ventanas de 12). Plugins con acciones admin deben usar Nonces o aparecen CVEs en Wordfence Threat Intelligence.
SPAs y REST APIs
SameSite=Stricten la cookie de sesion.- Cabecera
X-CSRF-Tokenen cada llamada. - O JWT en
Authorization: Bearer: sin cookies no hay CSRF, pero crece el riesgo XSS.
Incidentes reales
- Gusano Samy en MySpace (octubre 2005).
- YouTube 2008.
- Netflix 2006.
- Plugins WordPress (Forminator, LiteSpeed Cache, Royal Elementor Addons en 2024).
- Routers (estudio 2018, mas del 70 por ciento vulnerables).
Como ayuda InspectWP con CSRF?
InspectWP analiza las cabeceras Set-Cookie y reporta los atributos SameSite y Secure. Cookies sin SameSite se marcan en la seccion de seguridad.