¿La rotación de ID de sesión mejora la seguridad?

(creo) Entiendo por qué las identificaciones de sesión deben girarse cuando el usuario inicia sesión: este es un paso importante para evitar session fixation.¿La rotación de ID de sesión mejora la seguridad?

Sin embargo, ¿hay alguna ventaja en la rotación aleatoria/periódica de las ID de sesión?

Esto, en mi opinión, solo proporciona una falsa sensación de seguridad. Suponiendo que las ID de sesión no son vulnerables a la adivinación de la fuerza bruta y solo transmites la ID de la sesión en una cookie (no como parte de las URL), un atacante tendrá que acceder a tu cookie (probablemente husmeando en tu tráfico) para obtener tu ID de sesión. Por lo tanto, si el atacante obtiene una ID de sesión, probablemente también pueda oler la ID de la sesión girada, y por lo tanto la rotación aleatoria no ha mejorado la seguridad.

Fuente

2010-05-17 David Underhill

Si está utilizando identificadores de sesión almacenados en cookies, la fijación de sesión no es un problema. Revisé el documento que pegaste y veo cosas como usar DNS y XSS para poseer al usuario, que obviamente son problemas mucho más importantes (por no mencionar, separados) que la fijación de la sesión. Si tiene el identificador de sesión (con un nivel aceptable de entropía) almacenado en una cookie, no hay razón para rotarlo. La única razón para rotarlo sería porque es adivinable o vulnerable de alguna otra manera, en cuyo caso el usuario se apropia de todos modos.

Fuente

2010-05-17 03:34:24

Creo que es necesario rotar el ID de sesión (SID) cuando es necesario iniciar sesión, incluso si está almacenado en una cookie. Considere esto: el atacante examina el sitio web en una computadora compartida y se le asigna un SID (pero no inicia sesión). Entonces el atacante se aleja. Si el siguiente usuario inicia sesión y el SID no se gira, entonces el atacante conoce el SID y puede usarlo para enmascararse como el usuario que inició sesión. * Este escenario es un poco rebuscado * (con suerte, la computadora compartida todavía tiene cuentas separadas), * pero es posible *. –

Lo que usted dice es una vulnerabilidad grave (piense en quioscos). Asumí que el sitio asigna una nueva ID de sesión al iniciar sesión. Por supuesto, debe asignar una nueva identificación de sesión al iniciar sesión. Y no, este ataque no es descabellado en absoluto. –

de acuerdo. (nota: mi comentario fue principalmente en respuesta a la primera oración en su respuesta) –

El desarrollo web no es lo mío, pero ¿es posible que el usuario que inicia sesión sea un atacante? Por ejemplo, si inicio sesión y obtengo la ID de sesión 4, ¿puedo adivinar que la ID de sesión 5 pertenecerá a algún otro usuario, modificaré mi cookie local y luego actuaré como ese usuario?

Fuente

2010-05-17 03:07:41

Esa sería una posibilidad si las ID de sesión se generaran secuencialmente. Sin embargo, los buenos generadores de ID de sesión generan identificaciones aleatorias solo por esta razón, por lo que los atacantes no pueden adivinarlos. –

Suena como una idea tonta en general.

Sería un error para los usuarios si presionan el botón Atrás, ya que los enlaces en la página anterior ahora incluirían una identificación de sesión desactualizada. También puede descartar cualquier AJAX porque cada vez que se realiza una RPC en el servidor, todos los enlaces/formularios en la página requieren actualización ya que ahora tienen valores no válidos. En todo caso, esto es menos seguro porque significa que su aplicación se vuelve más complicada y tiene más posibilidades de cometer un error.

Si el razonamiento exige que usted "gire" identificadores probablemente significa que sus identificaciones están mal generadas, y eso debería ser lo que se arregle. Si husmear es un problema, use SSL.

Fuente

2010-05-17 03:07:56

No creo que esto cree un problema con el botón Atrás. Y creo que puede solucionar peticiones AJAX/casi simultáneas girando la ID de sesión cada N solicitudes y reteniendo las antiguas por un período corto. Por supuesto, solo porque no arruine esas cosas no significa que sea una buena idea. Estoy de acuerdo con usted en que tampoco creo que la rotación periódica de ID de sesión valga la pena. También estoy de acuerdo en que si espiar es un problema, SSL es obligatorio. –

Al no rotar/cambiar, ha dejado de girar efectivamente. ¿Qué ocurre si su aplicación es una sola página y nunca cambia? Su ajax en esa página finalmente será más antiguo que el ID de sesión TLD. –

Es una mala idea mantener sessionID en las URL de todos modos. Por lo tanto, si el ID de sesión se guarda ordenadamente en una cookie, los botones de retroceder/avanzar en un SPA no fallarían. – SteAp

De acuerdo con esta publicación de blog SSL Labs (desde 2013), los chipders RC4 (todavía vistos en libertad, 2017) son débiles y pueden permitir que un sombrero negro exhiba datos de cookies de sesión del tráfico HTTPS interceptado (como wifi).

ID/datos de la cookie de sesión giratoria cada x unidades de tiempo (¿minutos?), Y después de cada y número de solicitudes, se sugiere en la publicación del blog.

Fuente

2017-03-09 01:55:17

¿La rotación de ID de sesión mejora la seguridad?

Respuesta

Cuestiones relacionadas