Al enviar una cookie de vuelta al servidor, el navegador no devuelve la marca "segura": el servidor no puede verificar si la cookie enviada proviene realmente del origen "seguro" ( enlace ). En cambio, puede provenir del origen no seguro correspondiente ( enlace ). Además, un atacante puede usar MITM para sobrescribir cualquier cookie utilizando un origen no seguro: esta cookie inyectada también será enviada por el navegador al origen seguro.
Por lo tanto, un atacante podría usar un MITM para desconectar a alguien de cualquier sitio web de HTTP:
- Alice inicia sesión en el sitio enlace de B (el sitio puede ser un sitio web de HTTPS completo sin http: // sitio web correspondiente) y obtener un "cookie;
- Bob usa MITM para inyectar un
<img src="http://example.com">
(estesitiowebnonecesitaexistirenabsolutocomoseexplicaacontinuación)encualquierotrositiowebHTTPqueAliceestévisitando; - ElnavegadordeAliceobtienela"imagen" en enlace ;
- Bob forja una respuesta (es posible que el sitio web enlace ni siquiera exista en absoluto) y restablece la cookie de la sesión a cualquier valor;
- Alice está desconectada example.com.
Fijación de sesión
Usando una pequeña variación, Bob podría crear una cuenta de usuario falsa en enlace , iniciar sesión en ella, obtener el ID de sesión y configurarla usando la misma Técnica en el navegador de Alicia. De esta manera, se podría engañar a Alicia para que envíe información privada sobre la cuenta de usuario falsa. Bob puede iniciar sesión con esta cuenta falsa para obtener la información privada de Alice:
- Bob crea una cuenta en enlace con el inicio de sesión;
- Alice inicia sesión en enlace
- Bob inicia sesión en enlace utilizando su cuenta falsa y obtiene un ID de sesión para esta cuenta falsa;
- Bob MITM a
<img src="https://example.com"/>
encualquiersitiowebHTTPsimplequeAliceestévisitando; - ElnavegadordeAliceobtienela"imagen" en enlace ;
- Bob falsifica la respuesta y establece una cookie utilizando su ID de sesión;
- La siguiente solicitud de Alice en enlace es, de hecho, usar la cuenta falsa, pero puede que no lo note a menos que compruebe su inicio de sesión en cada página;
- Alice envía algunos datos privados en el sitio web (agrega un marcador, realiza una solicitud del motor de búsqueda, carga algunas fotos ...);
- Bob inicia sesión con la cuenta falsa y recupera los datos privados de Alice.
¿Hay alguna razón por la que no funciona? Hay alguna manera de evitar esto? ¿Este ataque tiene un nombre? ¿Hay alguna referencia o discusión disponible sobre esto (OWASP, documentos de seguridad ...)? ¿Se ha utilizado esta vulnerabilidad en la práctica? ¿Hay alguna solución / plan para solucionarlo agregando funcionalidad a los navegadores (tal vez un nuevo encabezado de cookie para cookies por origen)?
Esto se discute ligeramente en RFC 6265 sección 8.6 "Integridad débil".
Lo que describo se describe mejor en el documento "Defensas robustas para falsificación de solicitudes entre sitios" 2 como" Sobreescritura de cookies "(mencionado por fatfredyy).
Posibles soluciones
-
Use HSTS con includeSubDomains
No muy bien soportado (navegadores antiguos). El problema de Bootstrap fue señalado en una respuesta por Hendrik Brummermann.
-
Utilice el ID de sesión SSL para el seguimiento de la sesión en lugar de las cookies
El identificador de sesión SSL no puede ser inyectado por un atacante MITMing. ¿Las sesiones son estables con este tipo de configuración?
-
Utilice la autenticación de certificado de cliente para el seguimiento de sesiones en lugar de las cookies
No es muy fácil de usar (y carece de la funcionalidad estándar de "cierre de sesión").