Gestión de sesiones: comprobaciones de cookies, timeouts y logout

Una vez que el usuario ha iniciado sesión, el ID de sesión equivale de forma temporal al método de autenticación más fuerte que haya empleado la aplicación, ya sea una contraseña, un código de un solo uso, un certificado de cliente, una tarjeta inteligente o una huella dactilar. Si un atacante puede adivinar, capturar o fijar ese ID, pasa a ser el usuario y el formulario de login ni siquiera entra en juego. Por eso, probar las sesiones significa probar el ID, la cookie que lo transporta y lo que hace el servidor con él en el login, tras un periodo de inactividad y en el logout.

Esta checklist sigue la OWASP Session Management Cheat Sheet y la RFC 6265, la especificación de las cookies.

El propio ID de sesión

Empiece por cómo se genera el ID. La cheat sheet exige al menos 64 bits de entropía procedentes de un generador de números aleatorios criptográficamente seguro. Con ese tamaño estima unos 585 años para adivinar un ID válido, suponiendo 10 000 intentos por segundo y 100 000 sesiones válidas simultáneas. Si genera sus propios IDs en lugar de usar los del framework, recomienda al menos 128 bits y un valor único para cada sesión.

Busque partes fijas o predecibles. Un ID hexadecimal de 16 caracteres con la mitad fija tiene solo 32 bits de entropía, lo que no basta. Además, el valor no debe significar nada para el cliente: ni ID de usuario, ni rol, ni correo electrónico en su interior. Ese estado debe permanecer en el servidor.

Revise también el nombre. Los nombres por defecto, como PHPSESSID, JSESSIONID, CFID/CFTOKEN y ASP.NET_SessionId, le indican al atacante qué stack utiliza. La cheat sheet sugiere un nombre genérico como id.

No acepte nunca el ID en una URL. Los IDs en la URL se filtran a través de enlaces, logs, historial del navegador, marcadores, la cabecera Referer y buscadores, y además facilitan la fijación de sesión.

Si el acceso de lectura a su almacén de sesiones forma parte de su modelo de amenazas, los tokens en claro suponen un riesgo. La cheat sheet describe un diseño dividido: la cookie lleva un identificador y un verificador secreto, y el servidor guarda el identificador junto con el hash SHA-256 del verificador, que se compara en tiempo constante. El identificador por sí solo nunca se acepta.

Atributos de las cookies

La RFC 6265 define estos atributos para una cabecera Set-Cookie: Expires, Max-Age, Domain, Path, Secure y HttpOnly.

• Secure marca la cookie para conexiones seguras. La RFC advierte de que no ofrece integridad frente a un atacante activo en la red, así que no la trate como protección contra uno.
• HttpOnly debe estar en todas las cookies de sesión. Confirme el atributo en las herramientas de desarrollo del navegador.
• Domain y Path definen el ámbito. Mantenga ambos tan acotados como la aplicación permita.
• Expires y Max-Age indican al navegador cuánto tiempo conservar la cookie. No los utilice como su timeout.

Revise el resto de las cabeceras de respuesta con nuestra herramienta de cabeceras de seguridad.

Login, timeouts y logout

Un ID de sesión que el navegador ya tenía antes del login y conserva después es justo lo que explotan los ataques de fijación. Emita un ID nuevo cuando el usuario se autentique, de modo que el anterior deje de ser válido.

Los timeouts requieren dos límites. Un timeout de inactividad cierra las sesiones que nadie está usando. Un timeout absoluto cierra las sesiones que se mantienen activas indefinidamente, lo que limita durante cuánto tiempo sigue siendo útil un ID robado. Anote las cifras, hágalas más cortas para administración y pagos, y aplíquelas en el servidor comprobando el registro de sesión almacenado, no la fecha de caducidad de la cookie.

El logout debe destruir la sesión en el servidor. Borrar la cookie en el navegador no es suficiente, porque el identificador es la credencial: cualquiera que lo haya copiado antes puede seguir enviándolo. Tras el logout, el ID antiguo no debe corresponder a nada. La cheat sheet incluye además una sección sobre el almacenamiento en caché del contenido web y Clear-Site-Data, que merece la pena leer para saber qué conserva el navegador después del logout.

Utilice la gestión de sesiones integrada del framework siempre que pueda. La cheat sheet señala que estas implementaciones han tenido vulnerabilidades, así que ejecute la última versión y revise los valores por defecto.

Qué probar

1. Capture la cookie antes y después del login. La primera petición debe establecer realmente una cookie de sesión, así que compruebe que before.txt no está vacío. Guarde las credenciales en un archivo (creds.txt con user=test&pass=...) para que no queden en el historial del shell. Los dos IDs deben ser distintos.

curl -i -c before.txt https://app.example/login curl -i -b before.txt -c after.txt -d @creds.txt https://app.example/login

1. Cierre sesión con la cookie autenticada y reenvíe después el valor antiguo, tomado de la última columna de after.txt. Debe ser rechazado. Si el logout es un POST, añada -d '' al primer comando.

curl -i -b after.txt https://app.example/logout curl -i -b 'id=VALUE_FROM_AFTER_TXT' https://app.example/account

1. Inicie sesión, permanezca inactivo más allá del timeout de inactividad y envíe una petición. Debe exigir autenticación de nuevo.
2. Mantenga una sesión activa más allá del timeout absoluto. Aun así, debe terminar.
3. Inspeccione Set-Cookie en la respuesta del login y compruebe Secure, HttpOnly, y un Domain y un Path no más amplios de lo necesario.
4. Recopile unos cientos de IDs y compárelos. Los segmentos fijos y los valores secuenciales son hallazgos. Contraste el nombre de la cookie con los nombres por defecto de los frameworks indicados arriba.
5. Busque IDs de sesión en URLs dentro de la aplicación, los logs y los enlaces.

Informe de los hallazgos conforme a OWASP ASVS indicando la versión: v5.0.0-<chapter>.<section>.<requirement>. ASVS 5.0.0 se publicó el 30 de mayo de 2025 y sus requisitos se ofrecen en CSV. Añada a su hoja de pruebas una columna con el identificador de cada prueba, de modo que una prueba fallida se lea como un hallazgo que cita su requisito.

Por dónde empezar

1. Ejecute primero las pruebas 1 y 2 en el entorno de staging: la comparación del ID antes y después del login y, a continuación, el reenvío tras el logout.
2. Capture la cabecera Set-Cookie de su cookie de sesión y corrija los atributos que falten o sean demasiado amplios.
3. Compruebe cómo se generan los IDs. Si ha construido su propio generador, pase al del framework o confirme que usa una fuente aleatoria segura con al menos 128 bits.
4. Anote los timeouts de inactividad y absoluto, aplíquelos en el servidor y añada pruebas que fallen si alguien los elimina.
5. Haga que el logout elimine el registro de sesión del servidor y añada las pruebas de reenvío a su suite de regresión.