Probar la fijación de sesión cuando la cookie no se modifica

Question

Probar la fijación de sesión cuando la cookie no se modifica

#1 de Anders (2 votos)
#2 de iwaseatenbyagrue (0 votos)

0

Estaba probando una aplicación web donde las cookies (ID de sesión, valores de sesión) son las mismas en todo momento. Incluso después de que se lleva a cabo la autenticación exitosa, permanece sin cambios. El ID de sesión viaja en forma de una cookie HTTP.

Para investigar una vulnerabilidad de reparación de sesión, le envié a mi colega un enlace como http://yoursite.com/?SID=1209023 , porque pensé que el sitio web asignaría automáticamente el ID de sesión de la víctima 1209023 para la futura navegación de la víctima en el sitio. Pero no funcionó.

Por lo tanto, mi aplicación no se ve afectada de esta manera pero aún tiene las mismas cookies. ¿Hay alguna otra manera de probar la existencia de una vulnerabilidad de reparación de sesión en mi aplicación?

session-management session-fixation

pregunta Shakir 28.02.2017 - 09:57

fuente

2 respuestas

0

Podría considerar usar Burp y sobrescribir la cookie emitida por el servidor (autorización previa) con su propio valor.

O, aún más sencillo, puede iniciar una solicitud con cualquier valor de cookie que elija y validar si el servidor en cualquier punto la cambia (una sola solicitud sería suficiente para verificar).

Ya sabías que el valor de la cookie no se modificó después de la autenticación, por lo que el potencial está definitivamente ahí. Parece que solo necesitas calcular los parámetros correctos para usar.

La forma en que realmente lo explotas es otra cuestión, pero saber que hay una, y luego aceptar que probablemente deberías seguir las recomendaciones de OWASP y crear una nueva sesión de autenticación, es la mitad de la batalla.

respondido por el iwaseatenbyagrue 28.02.2017 - 13:20

fuente

Lea otras preguntas en las etiquetas session-management session-fixation

conexiones externas que deben confirmar el correo electrónico Desarrollando Exploits de Android [cerrado]

score 2 · Accepted Answer

Para que exista una vulnerabilidad de reparación de sesión, el servidor más guardado usa alguna entrada que usted (el atacante) puede controlar como valor para el ID de sesión. OWASP tiene una lista útil :

token de sesión en el argumento de la URL. (Esto es lo que intentaste. Pero ten en cuenta que el parámetro podría tener cualquier nombre, y debes averiguar qué es. No tiene que ser SID .)
token de sesión en un campo de formulario oculto.
ID de sesión en una cookie. Dado que no puede configurar las cookies en varios dominios, necesita alguna otra vulnerabilidad para aprovechar esto, como XSS o inyección de HTML (de una etiqueta META).

Si el servidor siempre establece un ID de sesión por sí solo, sin involucrar ninguna entrada del usuario en el proceso, esto podría no ser explotable.