fijación de sesión HTTP

2

Según wikipedia , Mallory, el atacante, obtiene su propio SID y luego obliga a Alice a visitar un sitio con el SID. ¿Por qué Mallory no tomaría el SID de Alice, si pudiera MITM Mallory? Además, ¿este ataque sin MITM solo es susceptible de SID en la cadena de consulta?

    
pregunta Adam 20.07.2016 - 20:48
fuente

2 respuestas

3

Mallory no quiere el ID de sesión de Alice. Mallory quiere que Alice realice acciones como ella misma, pero mientras el sitio web cree que es Mallory. Como usar su tarjeta de crédito para comprar algo que ella cree que obtendrá, pero que en realidad será acreditado a Mallory.

Hay varios vectores para este ataque. El que mencionas, las sesiones sin cookies con el identificador de sesión en la URL es uno. Mallory tiene el control de un subdominio y la capacidad de escribir cookies para un dominio principal es otra.

    
respondido por el Xander 20.07.2016 - 20:59
fuente
2

Dentro del alcance del artículo, el punto es que hay 2 métodos diferentes mediante los cuales Mallory obtiene el control sobre la sesión de Alice. Donde los métodos difieren es cuando se considera el mundo más grande en el que puede ocurrir un ataque de este tipo.

  • si Mallory puede hacer que Alices haga clic en un enlace y el sistema de destino permite establecer los identificadores de sesión a partir de una URL, entonces Mallory puede fijar el identificador de sesión.

Aquí no se requiere MITM.

  • un ID de sesión proporcionado al cliente a través de un canal seguro no se puede MITMed sin romper el canal seguro. Existen extensiones del protocolo http que permiten marcar una cookie para que solo sea devuelta a través de conexiones HTTPS. Pero las cookies establecidas a través de HTTP se devuelven a través de HTTP y HTTPS. Por lo tanto, si Mallory puede interferir con las comunicaciones HTTP de Alices, puede fijar el valor de la sesión que posteriormente se usará en un canal seguro.

Aquí solo hay un MITM del canal no seguro.

  • Si Mallory puede inyectar su javascript en cualquier página servida por el sitio de destino, por XSS, entonces puede configurar la fecha de la sesión. Si bien esto también le permitiría leer una cookie con el indicador de seguridad y, por lo tanto, secuestrar la sesión, HTTP solo tiene una opción HTTP, que oculta las cookies de javascript. Esto elimina el secuestro de la sesión en el navegador, pero no la fijación de la sesión.

Aquí, la mitigación del uso de HTTPS, incluso si se aplica con HSTS no es efectiva.

Solo el nombre de la cookie y su valor se devuelven al servidor, no las opciones con las que se creó, su ruta, host, esquema o tiempo de caducidad, ni ninguna otra cosa sobre la procedencia de los datos.

También hay situaciones en las que el secuestro es un ataque más efectivo que la fijación.

    
respondido por el symcbean 21.07.2016 - 01:18
fuente

Lea otras preguntas en las etiquetas