Session fixation: la trampa que hace que tú “entregues” tu sesión
A veces no te “roban” la sesión… te la dejan lista..
Session fixation es cuando el atacante logra que uses un ID de sesión que él ya conoce, y después solo tiene que “engancharse” a esa misma sesión para entrar como tú.
“Después del login, la sesión debe cambiar.”
Porque si no cambia… alguien más puede estar usando la misma.
¿Qué es session fixation en simple?
A veces no te “roban” la sesión… te la dejan lista.
Session fixation es cuando el atacante logra que uses un ID de sesión que él ya conoce, y después solo tiene que “engancharse” a esa misma sesión para entrar como tú.
Caso típico (muy real)
- El atacante obtiene un session ID válido del sitio (por ejemplo, entrando como invitado).
- Te lo “pega” por algún canal:
- Un link con un parámetro tipo ?sessionid=…
- Un subdominio o sitio que setea cookies de forma indebida (mala configuración de dominio)
- Un flujo de login que conserva el mismo ID de sesión antes y después de autenticarse
- Tú abres el enlace y luego inicias sesión normalmente.
- Si la app no regenera el ID de sesión tras el login, tu cuenta queda atada a ese ID.
- El atacante usa ese mismo session ID y entra como tú.
Resultado: secuestran tu sesión sin robar credenciales.
“Después del login, la sesión debe cambiar.”
Porque si no cambia… alguien más puede estar usando la misma.
¿Por qué pasa?
- La app permite fijar el ID (por URL, cabeceras o cookies débiles).
- El sistema de autenticación no renueva la sesión al autenticarse.
- Cookies mal configuradas (dominio demasiado amplio, sin HttpOnly, sin Secure, sin SameSite).
- Sesiones largas o sin invalidación.
Señales de alerta en tu aplicación
- El usuario puede pasar el ID de sesión por URL (por ejemplo ;jsessionid= o ?sid=).
- La sesión del “guest” se convierte en sesión autenticada sin cambio de ID.
- No se invalida la sesión anterior al hacer login.
- “Recordarme” o SSO que reusa tokens/sesión sin rotación.
Cómo se mitiga (checklist rápido)
✅ Regenerar el session ID después de login (y también después de elevar privilegios: admin, pagos, cambio de rol)
✅ Invalidar sesión anterior al autenticar (y al hacer logout)
✅ No aceptar IDs de sesión por URL (solo por cookies)
✅ Cookies bien configuradas:
- HttpOnly (mitiga robo por JS)
- Secure (solo HTTPS)
- SameSite=Lax o Strict según el caso
✅ Tiempo de vida razonable + rotación en eventos críticos
✅ Monitoreo: múltiples IP/UA usando el mismo session ID (anomalías)
“Después del login, la sesión debe cambiar.”
Porque si no cambia… alguien más puede estar usando la misma.
Suscríbete a Nuestro Blog: Mantente actualizado con las últimas noticias y consejos en ciberseguridad. Suscríbete ahora.
