Gestión de sesión: establezca un nuevo valor de ID de sesión después del cambio de privilegios y otras operaciones confidenciales

También es importante citar las oraciones anteriores:

  

La aplicación web debe renovar o regenerar la ID de sesión después de cualquier cambio de nivel de privilegio dentro de la sesión de usuario asociada. El escenario más común en el que la regeneración de ID de sesión es obligatoria es durante el proceso de autenticación, ya que el nivel de privilegio del usuario cambia del estado no autenticado (o anónimo) al estado autenticado. Otros escenarios comunes ...

En otras palabras, OWASP está resumiendo el caso en el que un usuario cambia lo que está autorizado a hacer o con lo que está autorizado. Daré un ejemplo de cada caso:

1. El usuario cambia lo que está autorizado a hacer: un usuario que inicie sesión en una cuenta diferente (por ejemplo, google "iniciar sesión como un usuario diferente") debe tener su sesión actual invalidada antes de poder iniciar sesión en la otra cuenta. Esto es importante porque mantienes una sesión abierta por un tiempo limitado (para que sea más difícil secuestrar una sesión).

   Ahora, si una de las cuentas para las que el usuario tiene credenciales está comprometida y la otra no, el atacante podría usar las sesiones superpuestas para ejecutar algo como la cuenta que no logró comprometer. Por lo tanto, es importante que se elimine la sesión anterior (no importa si la sesión anterior o la nueva es para una cuenta comprometida).

   Como extra, si un atacante puede forzar a un usuario que ha iniciado sesión en dos cuentas a cambiar entre ellas repetidamente, es posible que no cuente el tiempo de la sesión y sea vulnerable a la fijación. Es más fácil (y menos propenso a errores) simplemente invalidar la sesión en el lugar, que probar algoritmos inteligentes para mantener vivas ambas sesiones. Esto es menos probable, pero sigue siendo una forma de aumentar la superficie de ataque para un atacante.

2. El usuario cambia la forma en que está autorizado (en realidad se autentica, pero luego se autoriza): un usuario que cambia la contraseña debe destruir su sesión anterior en el acto porque eso es lo que el usuario espera que suceda. Si su sesión dura 10 minutos y un usuario cambia su contraseña, espera que un atacante que cree que tiene su contraseña ya no pueda acceder a su cuenta. No cree que el atacante pueda usar su cuenta durante 10 minutos más.

   Tenga en cuenta que este no es el mismo requisito que pedirle a un usuario que ingrese la contraseña anterior y la nueva en una pantalla de cambio de contraseña. Definitivamente debería hacer eso, ya que evita que un atacante en posesión de un ID de sesión cambie la contraseña del usuario. Pero lo que la cita de OWASP sostiene es sobre la destrucción de la sesión anterior en el momento en que se recibe la solicitud POST con el cambio de contraseña. Para que un atacante en posesión de una ID de sesión no pueda usar la cuenta de ese usuario en el momento en que se restablece la contraseña.

Considere un ejemplo común de cambio de privilegios: Amazon.

Si alguna vez ha usado Amazon, su navegador tiene una cookie persistente que le dice a Amazon quién es usted, incluso si no ha iniciado sesión. Cuando abre el navegador y navega a Amazon, mostrará su nombre en la parte superior derecha y tendrá la posibilidad de agregar artículos a su carrito. Puede llamar a esta autenticación de nivel 1.

La cookie de autenticación de nivel 1 tiene una vida útil muy larga (puede ser infinita) y es persistente, lo que significa que cualquier persona con acceso a su tienda de cookies podría robarla.

Ahora, supongamos que ha agregado algunos artículos a su carrito y desea completar una compra. En este punto, Amazon requerirá que ingrese su contraseña. Una vez que lo hayas hecho, tendrás privilegios adicionales. Puede llamar a esta autenticación de nivel 2.

La cookie de autenticación de nivel 2 es mucho más difícil de robar. Es una cookie de sesión solo para http y desaparece al cerrar el navegador. Y creo que solo funciona durante unos 30 minutos,

Nota: es imposible para el servidor saber si una cookie es solo de http o si es una cookie de sesión, porque un navegador solo presenta el valor de la cookie en sí, no sus atributos. Entonces, desde la perspectiva del servidor web, todo depende del valor de las cookies en sí.

Ahora imagine que Amazon no se molestó en cambiar el ID de sesión cuando inicia sesión. En su lugar, mantiene el mismo ID de sesión, pero almacena una variable de sesión que indica el privilegio elevado. Aquí hay un ataque plausible:

1. Hacker roba su cookie persistente, lo que solo le otorgará privilegios de nivel 1. No hay problema, ¿verdad?
2. Su navegador tiene una copia exacta de esta cookie.
3. En algún momento, navega a Amazon, decide completar una compra e inicia sesión.
4. La cookie ahora tiene privilegios de nivel 2.
5. Hacker ha estado golpeando el servidor de Amazon con esta cookie de vez en cuando para ver si ha iniciado sesión. Una vez que vea que ha subido al nivel 2, puede hacer todo lo que pueda, incluso enviándose un elemento o cambiando su contraseña.

Si el identificador de sesión cambió en el paso 3, este ataque se frustraría.