Revisor de Gestion de Sesiones

El Problema

La gestion de sesiones es donde la autenticacion se encuentra con la complejidad del mundo real. Sesiones que nunca expiran dan a los atacantes tiempo ilimitado para explotar cookies robadas. IDs de sesion generados con aleatoriedad debil pueden ser predichos. Los ataques de session fixation permiten a atacantes establecer un ID de sesion conocido antes de la autenticacion. Sin flags de cookie correctos, los tokens de sesion se filtran a traves de XSS, redes inseguras o peticiones cross-site.

El Prompt

Eres un especialista en seguridad de sesiones. Revisa la implementacion de gestion de sesiones de mi aplicacion en busca de vulnerabilidades.

IMPLEMENTACION DE SESION:
- Tipo: [ej. sesiones server-side con Redis, JWT en cookies, cookies cifradas]
- Framework: [ej. Express + express-session, Django sessions, Next.js]
- Config de cookies: [pega configuracion de cookies — nombre, flags, dominio, path, expiracion]
- Store de sesion: [ej. Redis, base de datos, memoria, sistema de archivos]

CODIGO:
[pega codigo de creacion, validacion, destruccion de sesion y configuracion de cookies]

Revisar estos aspectos de seguridad de sesion:

1. **Entropia del ID de sesion**: Se genera con aleatoriedad criptografica (128+ bits)?
2. **Flags de cookie**: HttpOnly, Secure, SameSite=Strict/Lax, scope correcto de Domain/Path?
3. **Session fixation**: Se genera nuevo ID de sesion despues del login?
4. **Timeout de inactividad**: La sesion expira despues de inactividad?
5. **Timeout absoluto**: Tiempo de vida maximo de sesion sin importar actividad?
6. **Sesiones concurrentes**: Pueden los usuarios ver y revocar sesiones activas en otros dispositivos?
7. **Revocacion de sesion**: Se pueden invalidar sesiones del lado del servidor?
8. **Logout completo**: El logout destruye la sesion en el servidor Y limpia la cookie en el cliente?
9. **Binding de sesion**: La sesion esta ligada a atributos del cliente (IP, User-Agent)?
10. **Nombre de cookie**: El nombre de la cookie evita revelar la tecnologia?

Para cada hallazgo, proporcionar nivel de riesgo y codigo de implementacion seguro.

Ejemplo de Salida

## Revision de Sesiones: 4 hallazgos

### ALTO: Cookie de sesion sin flag HttpOnly
Linea 12: cookie: { httpOnly: false }
Riesgo: Cualquier vulnerabilidad XSS puede robar la cookie de sesion via document.cookie.
Solucion: Configurar httpOnly: true.

### ALTO: Sin regeneracion de sesion despues del login
El ID de sesion permanece igual antes y despues de la autenticacion.
Riesgo: Session fixation — atacante establece cookie, victima inicia sesion, atacante tiene sesion autenticada.
Solucion: Llamar req.session.regenerate() inmediatamente despues de autenticacion exitosa.

Cuando Usar

Revisar gestion de sesiones al implementar autenticacion, cambiar backends de almacenamiento de sesion o modificar politicas de cookies. Esencial despues de incidentes de seguridad con session hijacking. Ejecutar antes del deploy a produccion.

Tips Pro

• Regenera el ID de sesion en cambios de privilegio — genera nuevo ID despues de login, elevacion de rol o cualquier cambio de privilegio para prevenir session fixation.
• Implementa timeouts de inactividad Y absolutos — el timeout de inactividad expira sesiones inactivas, el absoluto limita incluso sesiones activas. Ambos son necesarios.
• La revocacion server-side es obligatoria — borrar la cookie del lado del cliente no es suficiente. El servidor debe tambien invalidar la sesion en el store.
• Monitorea anomalias de sesion — registra cuando una sesion se usa desde una nueva IP o User-Agent y considera requerir re-autenticacion para acciones sensibles.