🔒 Registro cerrado · Apertura oficial próximamente · Acceso exclusivo para alumnos activos
Iniciar SesiónRevocar lo que no se puede revocar
5 tareas · 40 min · Principiante
A un organizador de eventos de Boletas Mavecure le robaron el portátil con la sesión abierta. Soporte cerró todas sus sesiones a primera hora y le cambió la contraseña. Por la tarde, alguien cambió la cuenta bancaria a la que se le liquida la venta de su concierto. Te entregan la configuración de los tokens, el caso de soporte y las peticiones de la cuenta ese día. La pregunta: por qué cerrar las sesiones no cerró nada.
Objetivo de la sala
A un organizador de eventos de Boletas Mavecure le robaron el portátil con la sesión abierta. Soporte cerró todas sus sesiones a primera hora y le cambió la contraseña. Por la tarde, alguien cambió la cuenta bancaria a la que se le liquida la venta de su concierto. Te entregan la configuración de los tokens, el caso de soporte y las peticiones de la cuenta ese día. La pregunta: por qué cerrar las sesiones no cerró nada.Una sesión clásica vive en el servidor: el navegador lleva un identificador y el servidor consulta en cada petición si esa sesión sigue viva. Cerrarla es borrar una fila. Un token autocontenido funciona al revés: el servicio lo valida con la firma, el emisor, la audiencia y la caducidad, sin preguntarle a nadie. Esa es su ventaja (ninguna consulta por petición) y su costo: lo que el servidor haga después no afecta a un token ya emitido, que sigue valiendo hasta su exp.
MITRE llama a lo que sale de ahí CWE-613, expiración insuficiente de la sesión. Las salidas son de diseño: tokens de acceso de vida corta (minutos), un token de refresco guardado en el servidor que sí se puede revocar, y una lista de identificadores (jti) revocados para emergencias, que solo sirve si todos los servicios la consultan.
Responde para continuar
Soporte pulsó «cerrar todas las sesiones» a las 09:10. ¿Por qué el token de acceso que ya tenía el ladrón siguió sirviendo?
Ver pista de ayuda
Piensa en qué consulta un servicio cuando recibe un token firmado.
El token de refresco existe para pedir tokens de acceso nuevos sin volver a escribir la contraseña. Por eso es la pieza más valiosa: mientras sirva, quien lo tenga puede renovar su acceso indefinidamente aunque cada token de acceso venza. Si además no se rota al usarse (cada uso entrega uno nuevo e invalida el anterior), ni siquiera hay forma de notar que dos personas lo están usando a la vez.
Abre el laboratorio y lee config-tokens.yml y registro-organizadores.txt.
Responde para continuar
¿Qué token de refresco siguió emitiendo tokens de acceso después del cierre de sesiones? Escribe su identificador tal como aparece.
Seguridad hizo lo correcto a las 11:30: puso el identificador del token de acceso en la lista de revocación. Pero una lista de revocación es un control distribuido; protege exactamente a los servicios que la consultan. Un servicio que la salta por rendimiento queda como si la lista no existiera.
Cruza la sección lista_revocacion de la configuración con las peticiones posteriores a las 11:30.
Responde para continuar
¿Qué servicio aceptó el token de acceso después de que se añadió a la lista de revocación? Escribe su nombre tal como aparece.
En el informe del caso hay que poner cuánto tiempo siguió operando el intruso después de que soporte creyó haberlo contenido. Mide desde el cierre de sesiones del ticket hasta la última petición aceptada desde la dirección desconocida.
Responde para continuar
¿Cuántos minutos pasaron entre el cierre de sesiones y la última petición aceptada del intruso? Escribe solo el número.
El equipo te pide una recomendación que no obligue a consultar la base de datos en cada petición, que era la razón para usar tokens autocontenidos.
Responde para continuar
¿Qué diseño habría cortado el acceso del intruso poco después de las 09:10?
Ver pista de ayuda
El intruso dependía de dos cosas: un acceso largo y un refresco que nadie tocó.
Whoami-Labs Pro
Whoami-Labs Pro utiliza cookies
Utilizamos cookies y almacenamiento local para el funcionamiento del sitio, seguridad de sesión y, si lo autorizas, analítica y marketing. Puedes aceptar, rechazar o personalizar. Política de Privacidad
Preferencias
Configuraciones de cookies
Elige qué categorías permitir. Las esenciales siempre están activas. Consulta la Política de Privacidad.
Esenciales
Siempre activas · sesión, CSRF, tema y esta preferencia
Necesarias para iniciar sesión, proteger formularios (CSRF) y recordar tu elección de cookies y tema. Sin ellas la plataforma no funciona de forma segura.
Analíticos
Hoy no activos en la plataforma; listos para cuando se conecten
Nos ayudan a entender uso de cursos y páginas. Si los activas, se usarán cuando conectemos analítica; hasta entonces no se carga ningún tracker.
Marketing
Hoy no activos; campañas futuras solo con tu permiso
Comunicaciones o campañas. No activos hoy en la plataforma; quedarán listos si los conectamos y solo si los permites.