Gestión de sesiones

Resumen

La gestión de sesiones es un mecanismo que compensa la naturaleza «sin estado» de HTTP y mantiene el estado de inicio de sesión del usuario entre una solicitud y otra. En origen, en HTTP cada solicitud es independiente y no tiene el contexto de las anteriores ni de las siguientes. En la gestión de sesiones, cuando la autenticación tiene éxito, el servidor emite un ID de sesión único y lo guarda en una Cookie del navegador. En las solicitudes siguientes, el servidor verifica el ID de sesión incluido en la Cookie y trata la solicitud como la de un usuario que ya ha iniciado sesión.

Cómo se genera y se guarda el ID de sesión

El ID de sesión se genera con un generador de números aleatorios criptográficamente seguro. Se usan, por ejemplo, UUID v4 o secuencias aleatorias de 256 bits. Se evitan los ID de sesión predecibles (números consecutivos, basados en la fecha y hora, etc.), porque son blanco de ataques de secuestro de sesión.

En el lado del servidor, la información del usuario vinculada al ID de sesión se guarda en una base de datos o en un almacén en memoria. Si se usa una base de datos NoSQL como DynamoDB, es eficiente un diseño en el que el ID de sesión es la clave de partición y se configura un TTL (fecha de caducidad) para borrar automáticamente las sesiones caducadas.

Atributos de seguridad de la Cookie

En la Cookie de sesión hay que configurar varios atributos de seguridad. El atributo HttpOnly prohíbe el acceso a la Cookie desde JavaScript y reduce el riesgo de que se robe el ID de sesión mediante un ataque XSS. El atributo Secure limita el envío de la Cookie a las comunicaciones HTTPS. El atributo SameSite mitiga los ataques CSRF.

Si te olvidas de configurar aunque sea uno de estos atributos, la superficie de ataque del secuestro de sesión se amplía. Sobre todo, si falta HttpOnly, cuando se aprovecha una vulnerabilidad XSS, un script puede leer el ID de sesión. Conviene activar todos los atributos de seguridad por defecto y no desactivarlos salvo que haya un motivo claro.

Comparación con JWT

Como alternativa a la gestión de sesiones existe JWT (JSON Web Token). Con JWT no se guarda la información de la sesión en el lado del servidor, sino que el propio token incluye la información del usuario. Como el servidor solo tiene que verificar la firma del token, no hace falta consultar la base de datos.

Sin embargo, JWT tiene un punto débil estructural: no se puede invalidar al instante un token ya emitido. Cuando el usuario cambia la contraseña o se detecta un acceso no autorizado, para anular a la fuerza los tokens existentes hace falta un mecanismo como una lista de bloqueo, y en esa medida el servidor pasa a tener estado. En la gestión de sesiones, si se borra el ID de sesión de la base de datos, esa sesión se puede invalidar en el lado del servidor.