Laboratorio de seguridad de sesiones
Revisa configuraciones de sesión, señala cada debilidad y elige la corrección: HttpOnly, Secure, SameSite, fijación, tiempos de expiración, cierre de sesión y __Host-.
Abrir la herramienta →La herramienta interactiva se abre en inglés.
La mayoría de las tomas de cuenta no son una contraseña rota: son una sesión rota. Revisas una cola de configuraciones de gestión de sesiones y das tu veredicto en cada una: endurecida, o el defecto concreto (una cookie sin HttpOnly o sin Secure, un SameSite que vuelve a abrir el CSRF, un ID de sesión que nunca rota (fijación de sesión), la falta de un tiempo de inactividad o de una vida máxima, un cierre de sesión que nunca llega al servidor o un problema con el prefijo __Host-), y después eliges la corrección: rotar el ID, poner SameSite=Lax, imponer un tiempo de inactividad o añadir el token a una lista de denegación al cerrar sesión. Se te puntúa por la tasa de detección frente a los falsos positivos: un SameSite=None correcto en una cookie de verdad entre sitios, una cookie de SSO legítima en el dominio padre y un cierre de sesión válido con tokens sin estado son trampas que NO debes señalar. Funciona íntegramente en tu navegador, con configuraciones escritas a mano y sin subir nada, y tras la evaluación cada configuración explica por qué su hallazgo y su corrección son los correctos. Es un laboratorio Pro: con una cuenta gratuita tienes 3 usos de herramientas Pro en total y después necesitas Pro.
- Lee cada configuración: atributos de la cookie, prefijo __Host- y ámbito, tiempos de expiración, rotación del ID y qué hace el cierre de sesión en el servidor.
- Da tu veredicto: segura o la debilidad concreta.
- Elige la corrección adecuada para cada debilidad.
- Revisa tu tasa de detección, tus falsos positivos y la explicación de cada configuración.
Preguntas frecuentes
¿Qué es el laboratorio de seguridad de sesiones?
Un ejercicio en el navegador en el que revisas configuraciones de gestión de sesiones (los atributos HttpOnly, Secure y SameSite de la cookie, el prefijo __Host- y el ámbito Domain/Path de la cookie, los tiempos de inactividad y de vida máxima, si el ID de sesión rota al iniciar sesión y al cambiar de privilegios, y qué hace realmente el cierre de sesión en el servidor) y en cada una decides si es segura o nombras la debilidad concreta, y después eliges la remediación correcta. Se te puntúa por cuántos problemas reales detectas y corriges frente a cuántas configuraciones endurecidas señalas por error.
¿Qué debilidades de sesión cubre?
Falta de HttpOnly (un XSS puede leer la cookie), falta de Secure (la cookie se filtra por HTTP en claro), un SameSite débil que vuelve a abrir el CSRF en una sesión de primera parte, fijación de sesión cuando el ID no se regenera al iniciar sesión o al elevar privilegios, la falta de un tiempo de inactividad, la falta de un límite de vida máxima, un cierre de sesión que solo borra la cookie del cliente mientras la sesión del servidor o el token sin estado siguen siendo válidos, y problemas con el prefijo __Host-: tanto una cookie sensible que debería estar fijada al host como una cookie __Host- invalidada por un atributo Domain.
¿Cómo se puntúa?
Cada configuración tiene un hallazgo correcto y una corrección correcta. Tu tasa de detección es la proporción de configuraciones vulnerables que identificas y remedias correctamente. Acertar el hallazgo pero no la corrección cuenta como un fallo parcial, y un falso positivo (señalar como vulnerable una configuración endurecida) lleva una penalización extra de higiene, porque una cola de alertas en la que los ingenieros no pueden confiar es tan inútil como una que pasa por alto defectos. Una partida perfecta acierta todas las configuraciones, incluidas las seguras.
¿Para quién es?
Para ingenieros de seguridad de aplicaciones y de IAM, desarrolladores de backend y de plataforma responsables de la autenticación y cualquiera que prepare una entrevista de seguridad y quiera entender por qué SameSite=None está bien en una cookie de verdad entre sitios pero es un agujero de CSRF en una de primera parte, por qué una cookie de SSO en el dominio padre no puede usar __Host- de forma legítima y por qué un cierre de sesión que nunca llega al servidor deja funcionando un token robado. Sin instalación y sin subir nada.
¿Es gratis?
No, es un laboratorio Pro. Con una cuenta gratuita tienes 3 usos de prueba de herramientas Pro en total; después necesitas Pro.