Rotación al iniciar sesión y al elevar privilegios

El identificador de sesión suele nacer antes del ingreso: la página de ingreso ya entrega uno, anónimo. Si el mismo valor sigue sirviendo después de que la persona se autentica, cualquiera que lo haya conocido antes (porque lo vio, porque lo puso él mismo o porque quedó en un registro) hereda la sesión autenticada sin haber tocado la contraseña.

La regla es emitir un identificador nuevo cada vez que cambia el nivel de privilegio de la sesión: al pasar de anónima a autenticada, al completar un segundo factor, al entrar en un modo de administración y al cambiar la contraseña. Y emitir uno nuevo solo sirve si el anterior deja de existir en el servidor en ese mismo momento. ASVS 5.0 lo pide en su capítulo de gestión de la sesión, y la guía de sesión de OWASP lo trata como la defensa principal contra la fijación.

En el panel, una contadora puede pasar a «modo administrador» de su empresa escribiendo otra vez su clave. Desde ahí crea usuarios y cambia la resolución de facturación, que es lo que hace válidas ante la autoridad tributaria las facturas que se emiten. Es una elevación de privilegio tan clara como el ingreso.

Abre ingreso.js en el laboratorio y compara las dos rutas.

La ruta de ingreso sí llama a la función que renueva. Pero renovar tiene dos mitades: dar un identificador nuevo y retirar el viejo. Si la segunda queda pendiente, el valor viejo sigue apuntando a una sesión del almacén con los mismos datos, y ahora esos datos son los de una persona autenticada: hay dos llaves para la misma puerta y la persona solo conoce una.

Lee renovar.js y fíjate en el orden en que ingreso.js llena la sesión y la renueva. Después busca en registro-sesiones.txt qué referencia aparece donde ya no debería.

El cliente pregunta si el ticket SVN-1187 importa y qué más hay que cambiar. Elige la corrección que cierra lo que viste en las dos tareas anteriores.