Efectos del nuevo token de sesión aleatorio para cada solicitud HTTP

Question

Efectos del nuevo token de sesión aleatorio para cada solicitud HTTP

#1 de MikeSchem (1 votos)
#2 de AlphaD (1 votos)

1

En una autenticación exitosa, una aplicación web emite una cookie de sesión que es una cadena de longitud constante de caracteres hexadecimales aparentemente aleatorios.

2E5F0FE4B7FCAB78CD967B46AB32915CCBFDC85316FAFB9174BDC4A3745339D8AD9C1D70A8EDD3D4F06107F3B1A67E85AEB1CB04F563818BC5D029D9E956652ED0F8F93E7A7EFD1E2E59DF1D378424964541E2C9B8A41436D0092A4114FBC4FA702A94C5090C34D97A3310F88CD3E9BDC8553230343BB1E4641F848102DF9B96AA81D6407273F774CFBD3E3FD68CAF84654B21E177A36DE7FB09EFC5A50A5253E1B5F5D6C5082A01D756CC68680FE1FBCA64CD72F1D6B1865C6FFC4B6BB8DE2C2B510731103F18DDA2289515F604632A26BD68B0E03647B854243EAFD7264B0765F45279BD6735E26D58DF720D5B9061EF316730

Esta cookie de sesión se envía para cada solicitud HTTP y la respuesta contiene un valor diferente cada vez, lo que significa que este valor solo se usa una vez. Cualquier cambio en este valor invalidará la sesión.

Por lo general veo valores de token de sesión que se usan muchas veces para una sesión de autenticación completa. En cuanto a la disposición de 'uso único' descrita anteriormente, veo:

Beneficios

reduce el riesgo de una sesión secuestrada, ya que es menos probable que el valor sea válido cuando un atacante intenta usar

Desventajas

aumentaron los recursos de computación requeridos para generar un token no aleatorio cada vez
posible drenaje de entropía del sistema operativo host por el uso constante de PRNG

¿Hay otras consideraciones que me estoy perdiendo aquí? Gracias

entropy cookies session-management cpu

pregunta user1330734 13.11.2018 - 05:28

fuente

2 respuestas

Lea otras preguntas en las etiquetas entropy cookies session-management cpu

Hacer una clave GNUPG2 fuera de línea - ¿Debo hacer solo la clave maestra S&E o S? comando de Linux para borrar archivos en una tarjeta SD?

score 1 · Answer 1

Esta solución ayudaría a protegerse contra un ataque de repetición desde un oyente pasivo, pero en caso de que estuvieras haciendo la sesión a través de HTTPS (como siempre deberías), sería difícil repetir la reproducción en cualquier caso.

Uno de los puntos en los que te recomendaría que pienses es qué pasará si el cliente no recibe una de las sesiones por cualquier motivo. ¿Aceptas alguno de los últimos 5? ¿Tienen que volver a autenticarse?

score 1 · Answer 2

Esta solución es en efecto similar a la de un mecanismo de tiempo de espera de renovación y tiene preocupaciones similares:

Tiempo de revocación

Si su ID de sesión anterior se revoca inmediatamente, existe la posibilidad de que su cliente aún no haya recibido el nuevo ID de sesión antes de intentar acceder a algún otro recurso con la sesión anterior. (Por ejemplo, su usuario puede impacientarse y hacer clic en algún otro enlace mientras su solicitud aún está en proceso o simplemente su aplicación está disparando muchas llamadas asíncronas).

Una forma de evitar esto es permitir un intervalo de seguridad donde todavía es posible usar el token antiguo para el acceso. Sin embargo, esto también significa que tendrá que mantener las dos sesiones sincronizadas para evitar la pérdida de datos al vencimiento del token anterior.

Condiciones de carrera

Todavía existe la posibilidad de que un atacante pueda renovar el ID de sesión con un ID de sesión válido antes de que lo haga un usuario. Si el atacante gana la carrera, el usuario encontrará que su sesión se corta repentinamente.

Si esto es más o menos probable con esta solución dependerá si también ha establecido un tiempo de espera inactivo (revocar si no hay actividad después de un período determinado) y un tiempo de espera absoluto (revocar después de un tiempo fijo) para su sesión. Si no tiene estos ajustes, su usuario podría, por ejemplo, navegar a una página y dejarla allí.

Necesidad

También está la cuestión de si se necesita o no el tiempo de espera de renovación para evitar el secuestro de la sesión. El tiempo de espera inactivo y el tiempo de espera absoluto con un vencimiento razonable ya pueden lograr resultados similares sin una carga adicional del servidor. También para prevenir el robo de sesión simple es suficiente simplemente usar SSL. En general, a menos que haya cambios en los derechos de acceso / nivel de privilegio del usuario, parece un poco redundante cambiar el ID de sesión.

referencia: Gestión de sesiones OWASP