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.