🧠 Ataque de Fijación de Sesión (Session Fixation) / Overloading
🧬 Teoría breve
Session Fixation es una vulnerabilidad en la que el atacante logra fijar una sesión válida en el navegador de la víctima antes de que se autentique, y luego secuestra esa sesión.
En su variante más moderna conocida como Session Variable Overloading, el atacante manipula variables de sesión o cookies para alterar la lógica de autenticación.
💡 El núcleo de ambos ataques es controlar o predecir la sesión de otro usuario.
🔐 ¿Cómo funciona?
- El atacante crea una sesión válida (sesion prefijada) en el sitio.
- Envía esa sesión (por link, cookie o header) a la víctima.
- La víctima inicia sesión sin saber que su sesión ya estaba fijada.
- El atacante reutiliza la misma sesión para hacerse pasar por ella.
🧪 Escenario: Ataque de Session Fixation contra un Admin
-
👨💻 Atacante: quiere acceder al panel de admin.
-
👑 Admin (víctima): tiene una cuenta privilegiada.
🧩 Paso a paso del ataque:
- 🧑💻 El atacante visita el sitio:
- Va a
https://example.com - El servidor le da una cookie: Set-Cookie: sessionid=XYZ123
- Va a
- 🪤 El atacante fija esa cookie para la víctima:
- Crea un link malicioso:
https://example.com/?sessionid=XYZ123 - O bien le envía un script XSS para forzar la cookie:
document.cookie = "sessionid=XYZ123";
- Crea un link malicioso:
- 🧑💼 El Admin entra al sitio usando ese enlace o ya con la cookie fijada
- Se loguea como
admin@example.com - El servidor asocia el ID de sesión
XYZ123a la cuenta admin
- Se loguea como
- 🧠 El atacante, que ya tenía
XYZ123, ahora la reutiliza- Va a
https://example.comcon su vieja cookie - ¡Y accede como admin sin haber sabido la contraseña!
- Va a
🔥 Resultado:
El atacante secuestra la cuenta del admin usando una sesión que él mismo controlaba desde el principio.
🧪 Parte Práctica – Lab OWASP SKF: sessionpuzzle
🚀 Despliegue del entorno
Primero descargamos la imagen:
docker pull blabla1337/owasp-skf-lab:sessionpuzzleLuego la ejecutamos con port forwarding:
docker run -dit -p 127.0.0.1:5000:5000 blabla1337/owasp-skf-lab:sessionpuzzle¿Qué significa cada opción?
-
-d→ detached (corre en segundo plano) -
-i→ interactivo (mantiene entrada estándar abierta) -
-t→ pseudo-TTY (simula terminal) -
-p→ redirige el puerto5000de tu host al5000del contenedor
🌐 Acceso a la aplicación
Ingresá a la aplicación desde tu navegador:
http://localhost:5000/
NOTE
Este laboratorio simula un Session Puzzle mediante manipulación de cookies (cookie tampering). Tu objetivo es interactuar con el usuario y capturar/modificar su sesión.
🧪 Prueba práctica con Burp Suite
-
Iniciá sesión como
admin : admin. -
Observá la cookie en el navegador:
Ctrl+Shift+I→ pestañaApplication→ secciónStorage→Cookies. -
Podés interceptarla con Burp Suite o inspeccionar su estructura.
Si la cookie tiene dos puntos (.) probablemente sea un JWT. -
Usá la herramienta web jwt.io para analizarla:
-
Pegás el token
-
Te muestra el header, payload y firma
-
Verificás si podés modificar el
payload(por ejemplo, el campousernameorole)
-
🧨 Posibles vectores de ataque
-
Enviar un enlace malicioso con una sesión prefijada.
-
Manipular directamente la cookie antes del login.
-
Cambiar parámetros sensibles como
user,isAdmin, etc., en el JWT. -
Si el servidor no valida correctamente las cookies, se puede asumir el rol de otro usuario.
🔒 ¿Cómo se previene?
| Medida | ¿Por qué ayuda? |
|---|---|
| 🔄 Regenerar ID de sesión al login | Invalida las cookies previas del atacante |
| 🧼 Invalidar sesiones viejas | Evita que sigan activas luego del login |
| 🔐 Cookies con atributos seguros | Protege contra fijaciones y lecturas vía JS |
| ❌ No aceptar sesión desde parámetros GET | Evita ataques vía enlaces |
📚 Referencias
📌 Tags
sessionfixation websecurity cookie jwt owasp burpsuite pentesting securitylabs docker