Falsificación de solicitudes entre sitios
La falsificación de solicitudes entre sitios es la vulnerabilidad en la que una página maliciosa hace que su navegador envíe una solicitud a un sitio en el que inició sesión, utilizando sus credenciales y realizando acciones que no autorizó. Las cookies de SameSite han cerrado la mayor parte de la superficie de ataque histórica, pero la clase subyacente aún importa dondequiera que las cookies autentiquen operaciones de cambio de estado.
El cuerpo completo del artículo se proporciona en inglés a continuación.
Falsificación de solicitudes entre sitios (CSRF, a veces denominada XSRF o "sea-surf") explota la confianza de un sitio web en el navegador del usuario. El atacante no puede ver sus cookies, pero el navegador las envía automáticamente con cada solicitud al origen al que pertenecen. Si el atacante puede hacer que su navegador realice una solicitud a un sitio en el que ha iniciado sesión, ese sitio verá una solicitud autenticada, incluso aunque el atacante la haya iniciado.
El ataque clásico
Imagínese un banco que procesa transferencias mediante una simple solicitud GET: https://bank.example/transfer?to=Bob&amount=1000. Has iniciado sesión en el banco. Un atacante le envía por correo electrónico un enlace o aloja una página con una etiqueta de imagen que apunta a https://bank.example/transfer?to=Attacker&amount=10000. Su navegador carga la imagen; el banco ve una solicitud autenticada de su sesión; la transferencia se realiza.
Ese ejemplo específico es principalmente histórico (los bancos ya no procesan transferencias a través de GET), pero el patrón es general. Cualquier solicitud de cambio de estado que se autentique únicamente a través de cookies de sesión es potencialmente vulnerable a CSRF.
Qué hace posible CSRF
Tres fundamentos:
- Las cookies se envían automáticamente. El navegador no pide permiso; las cookies pertenecen al origen y viajan con cada solicitud a ese origen, independientemente de dónde se inició la solicitud.
- HTML puede desencadenar solicitudes entre orígenes. Las etiquetas de imagen, los envíos de formularios, las etiquetas de script y varios otros elementos pueden apuntar a cualquier URL.
- Los servidores actúan sobre las solicitudes sin verificar la intención. El servidor ve una solicitud autenticada; sin protecciones CSRF explícitas, procesa la acción.
Las defensas estándar
- Tokens CSRF (tokens de sincronizador). El servidor incluye un token aleatorio en cada forma. Los envíos deben incluir el token. La página maliciosa del atacante no puede leer el token (política del mismo origen), por lo que las solicitudes falsificadas fallan. Los marcos web modernos generan y verifican tokens automáticamente.
- SameSite cookies. Las cookies marcadas SameSite=Lax (predeterminadas en los navegadores modernos desde 2020) no se envían en solicitudes entre sitios, excepto en las navegaciones de nivel superior. SameSite=Strict es aún más estricto. Este es el cambio más grande que redujo el riesgo de CSRF en los últimos cinco años.
- Validación del encabezado de origen y referencia. Los servidores pueden verificar que el encabezado de origen coincida con el origen esperado. Las solicitudes entre sitios tienen un origen diferente, lo que permite el rechazo.
- Cookie de envío doble. El servidor establece un valor tanto en una cookie como en un parámetro de solicitud independiente; El verificador comprueba que coincidan. Funciona sin estado de sesión del lado del servidor.
- Reautenticación para acciones confidenciales. Confirmación de contraseña, desafío MFA o autenticación intensificada en operaciones de alto valor. Derrota CSRF y varias otras clases de ataques simultáneamente.
La revolución de las cookies de SameSite
Antes de 2020, cada solicitud entre sitios llevaba las cookies del sitio de destino, incluidas las solicitudes de cambio de estado de páginas maliciosas. SameSite=Lax hizo que las cookies entre sitios fueran la excepción y no la regla. Los principales navegadores utilizaron Lax de forma predeterminada en 2020-2021, y el impacto fue dramático: la mayoría de las vulnerabilidades CSRF casuales dejaron de ser explotables de la noche a la mañana.
El problema: SameSite=Lax todavía permite cookies en navegaciones de nivel superior (redirecciones de página completa). Las operaciones de cambio de estado activadas al hacer clic en un enlace aún pueden contener cookies. La defensa es buena pero no completa.
SameSite=Strict lo impide por completo. La contrapartida: interrumpe los flujos de inicio de sesión que dependen de la navegación entre sitios (inicio de sesión único, redireccionamientos posteriores a OAuth). La mayoría de los sitios principales utilizan Lax de forma predeterminada y Strict solo en las cookies más confidenciales.
CSRF y API
Las API modernas a menudo se autentican mediante encabezados de autorización (tokens de portador) en lugar de cookies. CSRF no se aplica porque el navegador no incluye automáticamente encabezados arbitrarios en solicitudes de origen cruzado. El problema CSRF pertenece en gran medida a los sistemas autenticados por cookies.
Sin embargo, las API que combinan cookies para algunos flujos y tokens para otros pueden tener superficies CSRF sutiles. Utilice uno u otro de forma consistente.
CSRF y CORS
CORS (intercambio de recursos entre orígenes) define cuándo un navegador permitirá que JavaScript lea una solicitud entre orígenes. CSRF trata sobre si la solicitud es sent, con cookies. Están relacionados pero son distintos:
- CSRF evita que la página maliciosa cause la solicitud
- CORS evita que la página maliciosa lea la respuesta
Un ataque CSRF no necesita leer la respuesta, solo necesita que el servidor ejecute la acción. El navegador activa diligentemente la solicitud y obtiene una respuesta; Es posible que la página maliciosa no la vea, pero el daño ya está hecho. CORS no soluciona CSRF.
Incidentes famosos de CSRF
- Manipulación de la cola de Netflix (2006). Los investigadores descubrieron que las etiquetas IMG diseñadas podían agregar películas a su cola de Netflix sin su participación. La solución fueron los primeros tokens CSRF de uso generalizado.
- Variantes de adquisición de cuentas de YouTube a finales de la década de 2000.
- Eliminaciones del repositorio de GitHub a través de CSRF en 2012 (solucionado rápidamente).
- Numerosos Las vulnerabilidades CSRF del complemento de WordPress se informan cada año; el ecosistema de complementos todavía los produce a escala.
Para desarrolladores en 2026
- Utilice un marco con protección CSRF incorporada (Django, Rails, Spring, Laravel todos lo tienen)
- Verifique los tokens CSRF en cada solicitud de cambio de estado
- Establecer SameSite=Lax (o Estricto) en las cookies de sesión
- Para API, use tokens de portador en lugar de cookies cuando sea posible
- Requerir reautenticación para operaciones de alto riesgo
- No confíe solo en Origen/Referente: algunos clientes omiten estos encabezados
Para usuarios
No puedes defenderte directamente contra CSRF; es un error del lado del servidor. Los valores predeterminados del navegador moderno (SameSite=Lax) ayudan sustancialmente, pero usted depende de que cada sitio al que inicie sesión tenga protección implementada. Permanezca conectado sólo el tiempo que necesite; cerrar sesión en cuentas confidenciales cuando no estén en uso; y confíe en los principales sitios modernos: todos han tratado con CSRF en sus modelos de amenazas.
Preguntas frecuentes
- ¿Las cookies de SameSite acabaron con CSRF?
- Lo redujo sustancialmente pero no lo eliminó. SameSite=Lax (el valor predeterminado moderno) permite cookies entre sitios en navegaciones de nivel superior. SameSite=Strict también previene eso pero interrumpe los flujos legítimos. Los tokens CSRF siguen siendo la defensa recomendada; SameSite es una capa complementaria.
- ¿En qué se diferencia CSRF de XSS?
- XSS inyecta código malicioso en el sitio confiable y lo ejecuta con sus privilegios. CSRF engaña al navegador para que envíe una solicitud al sitio confiable sin inyectar nada. XSS puede hacer todo lo que CSRF puede hacer y más. Son diferentes mecanismos de ataque.
- ¿Puedo realizar pruebas de CSRF en mi propia aplicación?
- Sí. Intente enviar formularios sin el token o modificado; Si la acción se realiza, tienes CSRF. Pruebe en Chrome con la aplicación de SameSite; Algunos marcos heredados tienen tokens CSRF que en realidad no están verificados. La revisión manual es sencilla.
- ¿Las aplicaciones de una sola página necesitan protección CSRF?
- Si se autentican mediante cookies, sí. Si se autentican a través de tokens de portador almacenados en el lado del cliente (almacenamiento local), son menos vulnerables a CSRF pero más expuestos a XSS. Ambas superficies de ataque importan; Elija su mecanismo de autenticación teniendo ambos en mente.
- ¿CSRF todavía está en el Top 10 de OWASP?
- Salió del Top 10 en 2021 debido a la mitigación generalizada a nivel del marco y a los valores predeterminados de las cookies de SameSite. Todavía está en la lista OWASP de vulnerabilidades importantes; ha disminuido la prevalencia, no el mecanismo subyacente.