cookie de sesión sin estado y cierre de sesión

Question

cookie de sesión sin estado y cierre de sesión

#1 de Tom Leek (3 votos)
#2 de Xander (2 votos)

2

He implementado una cookie de sesión sin estado, algo como las líneas de este artículo:

Desmitificando la autenticación web (cookies de sesión sin estado)

La cookie contiene un tiempo de caducidad dentro del valor de hash, y también la cookie se configura con un tiempo de espera de sesión en el navegador. Cuando el usuario cierra la sesión, la cookie se elimina. Sin embargo, alguien notó que un atacante puede robar la cookie y esencialmente usarla dentro del tiempo de caducidad especificado en la cookie aunque el usuario haya cerrado la sesión. ¿Existe una solución para este problema (además de deshacer la cookie de sesión sin estado y usar la administración de sesión estándar de servidor / marco)?

web-application authentication exploit

pregunta V1400 27.10.2014 - 21:19

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application authentication exploit

¿Alguna forma de proteger mis datos de usuario en las computadoras de la compañía? ¿Cómo explotar las vulnerabilidades encontradas en OpenVAS?

score 3 · Answer 1

El punto central de tener una cosa "sin estado" es evitar mantener estado (aquí, en el lado del servidor). Los servidores sin estado están sujetos inevitablemente a ataques de repetición , por definición. El problema que estás imaginando es básicamente un ataque de repetición.

Si los atacantes pueden robar las cookies de los clientes, entonces ya tienes problemas más grandes. Si no pueden, entonces no hay problema. Utilizar SSL.

(SSL no es la solución definitiva para todo, pero ayuda a evitar el robo de cookies, al menos siempre que la cookie esté marcada como segura y solo HTTP . )

score 2 · Answer 2

No, realmente no lo hay. Para realizar este trabajo, debe tener implementado algún tipo de administración de sesión para determinar si el token en una cookie es válido o no. Pueden significar mantener una lista de sesiones válidas como en la administración de sesión tradicional o listas de listas explícitas que han caducado durante algún tiempo. (Menos gastos generales en la aplicación, pero mucho más difíciles de hacer correctamente).

En última instancia, esta es una amenaza de bajo riesgo en general, y en mi opinión, generalmente no vale la pena mitigarla. Es completamente contrario al modelo de solicitud-respuesta de la web, y puede protegerse contra el robo de token adecuadamente usando simplemente TLS y HTTPS.