Explotación de una vulnerabilidad potencial de fijación de sesión de la aplicación web ASP.NET

Navega tus respuestas
2

Estoy probando con lápiz una aplicación ASP.NET que muestra un comportamiento de Fijación de sesión . La aplicación está utilizando sesiones basadas en cookies . Básicamente:

  1. Cuando llegas a la página, no se crea una cookie de sesión
  2. Después de que se haya creado el inicio de sesión ASP.NET_SessionId se creará una cookie
  3. En el cierre de sesión y el inicio de sesión repetido, el valor de la cookie sigue siendo el mismo (no hay regeneración del valor de la cookie)

He podido realizar el ataque de fijación de sesión manualmente :

  1. He aterrizado en la página
  2. Creé manualmente una cookie ASP.NET_SessionId con algún valor (para el atacante)
  3. Abrí una nueva sesión del navegador y configuré exactamente la misma cookie (para la víctima)
  4. Inicié sesión como víctima en esta nueva sesión del navegador
  5. En la sesión del navegador del atacante, ahora podía navegar por el sitio web como víctima

Ahora estoy teniendo problemas para explotar esta vulnerabilidad de reparación de sesión en condiciones reales. Necesito crear o modificar la cookie ASP.NET_SessionId de alguna manera. Por lo que puedo decir, no hay una vulnerabilidad de XSS en el sitio web que pueda usar.

He estado jugando con las dos variaciones de ataque más notables pero sin suerte (un caso en el que una víctima haría clic en un enlace que establecería una cookie en la página web):

  • JavaScript

https://www.example.com/<script>document.cookie='ASP.NET_SessionId=THISISAFIXATEDCOOKIE; expires=Thu, 18 Dec 2015 12:00:00 UTC; path=/; domain=example.com; path=/'</script>

  • Inyección de HTML

https://www.example.com/<meta http-equiv=Set-Cookie content="ASP.NET_SessionId=THISISAFIXATEDCOOKIE; expires=Thu, 18 Dec 2015 12:00:00 UTC; path=/; domain=example.com; path=/">

Lo que sea que haya intentado, he llegado a una página de error predeterminada o a la página de destino sin una cookie creada / modificada.

¿Me estoy perdiendo algo con estos dos vectores de ataque?

¿Hay algún otro método que pueda intentar para crear o modificar la cookie ASP.NET_SessionId de la víctima además de usar man-in-the-middle o man-in-the browser (basado en malware) ataques?

    
pregunta fing 26.02.2015 - 10:13
fuente

2 respuestas

1

Parece que ha copiado los ataques de ejemplo directamente desde la página OWASP en Fijación de sesión .

Para aclarar: se pretende que sean ejemplos específicos de un sistema que tiene otra vulnerabilidad además de la Fijación de sesión (XSS, Inyección de HTML, etc.); no son ataques que puedan funcionar en una situación real.

Si quisieras ejecutar este ataque, habría dos pasos:

  1. Encuentre una vulnerabilidad que le permita configurar la autenticación cookie para otro usuario. Tu mejor mejor probablemente sería XSS o Inyección de HTML. Para encontrar este tipo de vulnerabilidad deberías Probablemente quiera hacer una evaluación de seguridad del sitio donde catalogar todas las solicitudes HTTP que se pueden hacer. Usted entonces fuzz todas las entradas a nivel HTTP de forma automatizada y Busque indicaciones de que existe una vulnerabilidad. Por posible vulnerabilidades en las que irías y probarías manualmente para ver si hay algo está realmente allí.

  2. Si encuentra alguna vulnerabilidad en la etapa anterior, podría luego intenta un ataque de Fijación de sesión

Espero que esto ayude.

    
respondido por el Abe Miessler 11.03.2015 - 17:35
fuente
0

Correcto, un requisito previo para un ataque de fijación de sesión es que el atacante pueda colocar un identificador de sesión (cookie) en la máquina de la víctima. Dado que las cookies están vinculadas al dominio por el que se emiten, esto no puede suceder en el curso normal de las cosas; es decir, el atacante necesita una forma de inyectar una cookie que parece provenir del sitio de destino.

En la práctica, esto significa explotar otra vulnerabilidad en la aplicación de destino, como XSS. Eso es lo que intentan hacer las URL de ejemplo, pero si la página de destino no es vulnerable a ese ataque, entonces no funcionará. La fijación de la sesión es una vulnerabilidad secundaria, ya que requiere alguna otra debilidad explotable para realizar un ataque. En la práctica, es más fácil realizar los cambios necesarios para evitar los ataques de fijación de sesión que probar que no existen vulnerabilidades de XSS.

OWASP siempre es una buena referencia.

    
respondido por el bmm6o 11.03.2015 - 16:54
fuente

Lea otras preguntas en las etiquetas

¿Está bien usar solo el nombre de usuario / contraseña para asegurar una página de administrador para moderar un sitio web? Riesgo en el mundo real de que Cisco ASA 5505 ejecute el modo agresivo IKEv1 con PSK