Ciberseguridad
CSRF
Ataques
La trampa está en confundir sesión válida con intención del usuario. El navegador puede llevar credenciales; el servidor sigue teniendo que decidir si acepta esa acción. Ahí se rompe el ritual.
Cross-Site Request Forgery consiste en provocar que el navegador de una persona envíe una solicitud no deseada a una aplicación donde tiene una sesión activa. Si el servidor la acepta, la acción ocurre con los permisos de esa persona. El atacante no necesita conocer su contraseña ni leer la respuesta para causar el cambio. OWASP: CSRF.
La sesión está abierta, pero la intención no está validada
Ejemplo inventado: tienes abierta una aplicación que permite cambiar el correo de tu cuenta. Desde otra página te inducen a enviar una petición a ese endpoint. El fallo aparece si la aplicación acepta el cambio basándose solo en las credenciales que acompañan la solicitud.
Ahora... eso no significa que cualquier petición entre sitios vaya a llevar todas las cookies. Depende de sus atributos y del contexto del navegador.
Qué revisar al desarrollar
- Usar la protección CSRF del framework y validar los tokens en el servidor para las acciones que modifican estado.
- Configurar
SameSitecomo una capa adicional, revisando el flujo real de autenticación. - Evitar operaciones que cambien datos mediante
GET. Cambiar aPOST, por sí solo, tampoco resuelve el problema. - Revisar las vulnerabilidades XSS: pueden permitir saltarse las defensas contra CSRF.
La guía de prevención de OWASP desarrolla estas medidas. Para recordar la diferencia: en CSRF importa que el servidor acepte una acción que el usuario no quiso realizar; en XSS, la ejecución de contenido malicioso dentro del contexto del sitio.
Vuelve al mapa de exploits y vulnerabilidades para comparar ataques.
+----------------------------------------+
| Floure & |
| Tachibana's guild |
| [Hikari · Nozomi] |
| SEAL: sha256/12: 8b80e581585b |
| STATUS: LITURGY_IN_PROGRESS |
+----------------------------------------+