Inyección / invalidación de sesión MITM

1

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:

  1. 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;
  2. Bob usa MITM para inyectar un <img src="http://example.com">(estesitiowebnonecesitaexistirenabsolutocomoseexplicaacontinuación)encualquierotrositiowebHTTPqueAliceestévisitando;
  3. ElnavegadordeAliceobtienela"imagen" en enlace ;
  4. 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;
  5. 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:

  1. Bob crea una cuenta en enlace con el inicio de sesión;
  2. Alice inicia sesión en enlace
  3. Bob inicia sesión en enlace utilizando su cuenta falsa y obtiene un ID de sesión para esta cuenta falsa;
  4. Bob MITM a <img src="https://example.com"/>encualquiersitiowebHTTPsimplequeAliceestévisitando;
  5. ElnavegadordeAliceobtienela"imagen" en enlace ;
  6. Bob falsifica la respuesta y establece una cookie utilizando su ID de sesión;
  7. 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;
  8. Alice envía algunos datos privados en el sitio web (agrega un marcador, realiza una solicitud del motor de búsqueda, carga algunas fotos ...);
  9. 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

  1. Use HSTS con includeSubDomains

    No muy bien soportado (navegadores antiguos). El problema de Bootstrap fue señalado en una respuesta por Hendrik Brummermann.

  2. 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?

  3. 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").

pregunta ysdx 19.07.2012 - 16:02
fuente

2 respuestas

1

Sí, este ataque funciona en la práctica.

Para el propietario de un sitio, hay básicamente dos formas de mitigar este ataque:

  • HSTS, pero el mismo HSTS es vulnerable a un atacante activo en la primera solicitud.
  • muestra el nombre de usuario / la imagen de perfil del usuario que inició sesión, pero esto es vulnerable a un ataque inteligente.

En teoría, este ataque podría evitarse con un cambio de protocolo: si el navegador hubiera incluido el dominio y la información http / https en el encabezado de la cookie, el servidor podría verificarlo.

Los navegadores podrían eliminar las cookies seguras en cualquier intento de modificación por una fuente http. Ignorar tales modificaciones es una mala idea porque romperá el cierre de sesión en algunas páginas.

    
respondido por el Hendrik Brummermann 19.07.2012 - 22:54
fuente
3

Realmente no entiendo lo que está diciendo, pero intentaré entender / explicar algunas cosas.

En primer lugar, el indicador seguro en cookie significa que este valor de cookie solo se enviará cuando se acceda al sitio a través de la conexión HTTPS .

En segundo lugar, las cookies se basan en el dominio y la ruta, por lo que no se enviarán a otro dominio o ruta.

El ataque que está describiendo se conoce como ataque de inicio de sesión CSRF, descuidado / subestimado en gran parte y marcado como pequeño impacto de ataque de impacto pequeño (imho falsamente). Puede leer más en: "Defensas robustas para falsificación de solicitudes entre sitios"

Y, finalmente, si el atacante puede montar MITM con HTTP, es muy poco lo que podemos hacer y nada será tan seguro como HTTPS. Así que estaré de acuerdo con usted, para que los sitios seguros sean HTTPS completos solo o no lo sean en absoluto. Además, como medida adicional, los navegadores web podrían evitar anular una respuesta HTTP de forma segura de cookie.

    
respondido por el damiankolasa 19.07.2012 - 19:52
fuente

Lea otras preguntas en las etiquetas