Gestión de sesiones

La sesión es el puente entre “me autentiqué una vez” y “el servidor me reconoce en cada petición”. Si ese puente es predecible, robable o no caduca, la autenticación entera no vale: da igual lo fuerte que sea la contraseña si el identificador de sesión se puede adivinar, interceptar o reutilizar indefinidamente.

Modelo de amenaza

Un identificador de sesión es, de facto, una credencial temporal. El atacante gana si puede: predecirlo (entropía baja), capturarlo (XSS, red sin TLS, logs), fijarlo (session fixation) o seguir usándolo después de que debería haber muerto (logout/timeout que no invalidan en servidor). El fallo más común no es criptográfico: es que el servidor confía en un token que nunca revoca.

Anatomía

Set-Cookie: session=4f8a...; HttpOnly; Secure; SameSite=Lax; Path=/

Los atributos de la cookie son la mitad de la defensa. Sin HttpOnly el JS la lee (XSS → robo). Sin Secure viaja en claro. Sin SameSite va en peticiones cross-site (CSRF).

Red Team

Descubrimiento

Inspecciona la cookie de sesión: longitud, charset, ¿parece aleatoria o codifica algo (base64 de user id)?
Compara varios tokens emitidos seguidos: si incrementan o comparten prefijo → entropía baja, predecible.
Revisa atributos: ¿falta HttpOnly/Secure/SameSite?

A mano

Fijación de sesión: si el servidor acepta un ID de sesión que tú fijas (por URL o cookie) y no lo rota tras el login, pones tu ID en el navegador de la víctima, ella se loguea, y tu ID queda autenticado.

1. GET https://target/?SESSIONID=atacante_fijo   (o Set-Cookie vía XSS/subdominio)
2. la víctima se autentica con ese mismo ID
3. el atacante usa SESSIONID=atacante_fijo -> sesión autenticada

No invalidación en logout: captura el token, haz logout, reenvía una petición con el token viejo. Si sigue válido → el logout es cosmético.
Timeout inexistente: token válido horas/días después de la última actividad.
Reutilización concurrente: el mismo token vale desde dos IPs a la vez sin alerta.
Token en URL: aparece en Referer, logs de proxy e historial → robo pasivo.

Predicción

Si el ID codifica datos (base64("user=5:ts=...")) o es secuencial, genera IDs de otros usuarios. Mide la entropía con Burp Sequencer.

Herramientas

Burp Suite — Sequencer (entropía), repetición de tokens, análisis de cookies.
cookie-editor / DevTools — manipular atributos.

Impacto

Suplantación total de la cuenta víctima sin conocer su contraseña, persistencia tras cambios de credencial si el token no se revoca.

Blue Team

Detección

Mismo session ID desde IPs/geografías/user-agents dispares simultáneamente.
Uso de un token tras un evento de logout.
Volumen de peticiones con tokens inexistentes/expirados (bruteforce de predicción).

Telemetría

Vincula cada sesión a su usuario, IP de origen y hora de emisión; registra logout e invalidaciones.

Hardening

IDs de sesión con ≥128 bits de entropía de un CSPRNG, opacos (sin datos embebidos).
Rota el ID al autenticar y al elevar privilegios (anula la fijación).
Invalida en servidor al hacer logout; no basta con borrar la cookie en cliente.
Timeout de inactividad y absoluto; re-autenticación para acciones sensibles.
Cookie con HttpOnly, Secure, SameSite=Lax/Strict, __Host- prefix, Path=/.
Nunca el token en la URL; siempre sobre TLS.

Respuesta

Invalida todas las sesiones afectadas, fuerza re-login global, rota el secreto de firma si las sesiones son firmadas (JWT/stateless).

CVEs y casos reales

Session fixation — clase clásica (OWASP); múltiples frameworks históricos no rotaban el ID tras login.
CVE-2023-34362 (MOVEit) — explotación encadenada que abusó de sesiones/tokens tras SQLi.
Moodle / Jenkins / foros PHP — numerosos CVE de tokens de sesión predecibles o no invalidados en logout.
Firesheep (2010) — demostración masiva de robo de sesión por falta de TLS en redes WiFi abiertas.

Checklist de prueba

¿El ID de sesión tiene entropía suficiente? (Burp Sequencer)
¿Se rota el ID tras el login? (fijación)
¿El logout invalida el token en servidor?
¿Existe timeout de inactividad y absoluto?
¿El mismo token vale desde dos orígenes a la vez?
¿La cookie tiene HttpOnly, Secure, SameSite?
¿El token aparece alguna vez en la URL?
¿El ID codifica datos manipulables en lugar de ser opaco?