Session Fixation

La Session Fixation aprovecha que una aplicación no renueva el identificador de sesión al autenticarse. Si el atacante consigue fijar de antemano un identificador conocido en el navegador de la víctima y la aplicación lo conserva tras el login, ese mismo identificador queda autenticado y el atacante, que ya lo conoce, hereda la sesión. La diferencia con el robo de cookie es sutil pero clave: aquí no se roba el id después, se impone antes.

El vector típico: la aplicación acepta un sessionid que llega por URL o por una cookie que el atacante puede sembrar (por open redirect, subdominio o un XSS), y no lo rota al iniciar sesión. El atacante fija el valor, induce a la víctima a autenticarse y reutiliza el id ya validado.

# 1) el atacante fuerza un id conocido en la victima
https://app.example.com/login?sessionid=ATACANTE_FIJO
# 2) la victima se loguea; la app NO rota el id -> ATACANTE_FIJO queda autenticado
# 3) el atacante usa ese mismo id y entra como la victima
Cookie: sessionid=ATACANTE_FIJO

Una variante emparentada (session puzzling) es cuando un flujo secundario asigna una sesión válida sin autenticar: por ejemplo, un "recuperar contraseña" que en su respuesta devuelve un token de sesión utilizable, permitiendo entrar a zonas privadas sin credenciales. La comprobación se hace observando en Burp si la respuesta de ese flujo trae un Set-Cookie/JWT que ya sirve para navegar autenticado.

Requisitos. La aplicación debe (1) aceptar un identificador de sesión influenciable por el atacante (por URL, cookie sembrable o un flujo que lo emita) y (2) no regenerarlo tras el cambio de privilegio (login, elevación). Si el servidor emite un id nuevo y aleatorio al autenticar, el id fijado queda anulado y el ataque falla.

Cómo detectarlo. En el log, la firma es un mismo identificador de sesión usado antes y después del login (no cambia al autenticar) y, a menudo, el mismo id apareciendo desde dos direcciones IP distintas (atacante y víctima). Un flujo de recuperación que emite tokens de sesión válidos sin autenticación previa es otra señal directa en el análisis de respuestas.

Defensa. Regenerar el identificador de sesión en cada cambio de privilegio (tras el login y tras la elevación), no aceptar id de sesión por URL, marcar las cookies HttpOnly, Secure y SameSite, y no emitir sesiones válidas en flujos que no autentican. Se relaciona con la gestión de tokens del JWT y con el robo de sesión del XSS.