django - qué - man in the middle wifi

¿Cómo funciona este ataque Man-In-The-Middle?

Question

La documentación de Django sobre su protección CSRF establece que:

Además, para las solicitudes HTTPS, CsrfViewMiddleware realiza una comprobación estricta del remitente. Esto es necesario para abordar un ataque Man-In-The-Middle que es posible bajo HTTPS cuando se usa una sesión independiente de la sesión, debido a que los encabezados HTTP ''Set-Cookie'' son (desafortunadamente) aceptados por los clientes que están hablando con un sitio bajo HTTPS. (La comprobación del Referer no se realiza para solicitudes HTTP porque la presencia del encabezado del Referer no es lo suficientemente confiable en HTTP).

Tengo problemas para visualizar cómo funciona este ataque. ¿Alguien podría explicar?

ACTUALIZACIÓN :
La redacción en el documento de Django parece implicar que hay un tipo específico de ataque Man-in-the-middle (que lleva a un CSRF exitoso, supongo) que funciona con nonce independiente de la sesión (pero no con nonce específico para la transacción, etc.) ., Supongo) e implica el uso del encabezado ''Set-Cookie''.
Así que quería saber cómo funciona ese tipo específico de ataque.

Answer 1

El atacante puede configurar la cookie CSRF utilizando Set-Cookie, y luego proporcionar un token coincidente en los datos del formulario POST. Dado que el sitio no vincula las cookies de sesión con las cookies de CSRF, no tiene forma de determinar si las token + cookie de CSRF son auténticas (el hashing, etc.) no funcionará, ya que el atacante solo puede obtener un par válido. desde el sitio directamente, y usar ese par en el ataque).

Directamente desde el proyecto django.

(Busqué en Google para la sesión independiente ).

Answer 2

Aquí hay una descripción muy detallada de uno de tales ataques MitM. A continuación se muestra una adaptación abreviada y simplificada:

Asumir que:

• el sitio atacado es foo.com
• Nosotros (el atacante) podemos mitmar todas las solicitudes.
• algunas páginas se sirven a través de HTTP (por ejemplo, http://foo.com/browse )
• algunas páginas se sirven a través de HTTPS (por ejemplo, https://foo.com/check_out ), y esas páginas están protegidas por una cookie de inicio de sesión (w / Secure set). Tenga en cuenta que esto significa que no podemos robar la cookie de inicio de sesión del usuario.
• todos los formularios están protegidos comparando un parámetro de formulario con la cookie csrftoken . Como se señala en los documentos de django, es irrelevante para este ataque, ya sea que estén "firmados" o simplemente no sean aleatorios.

Agarra un token CSRF válido

• simplemente lea el tráfico cuando los usuarios visiten http://foo.com/browse
• o, si los tokens son específicos del formulario, podemos iniciar sesión en el sitio con nuestra propia cuenta y obtener un token válido de http://foo.com/check_out por nuestra cuenta.

MitM forzará la página POST a HTTPS controlada por el atacante con ese token:

Modifique una página servida por HTTP (por ejemplo, http://foo.com/browse ) para tener un formulario de envío automático que se envíe a un punto final de HTTPS POST (por ejemplo, http://foo.com/check_out ). También establece su cookie CSRF para que coincida con su token:

<script type="text/javascript">
  function loadFrame(){
    var form=document.getElementById(''attackform'');
    // Make sure that the form opens in a hidden frame so user doesn''t notice
    form.setAttribute(''target'', ''hiddenframe'');
    form.submit();
  }
</script>

<form name="attackform" id="attackform" style="display:none" method="POST" 
      action="http://foo.com/check_out">
  <input type="text" name="expensive-thing" value="buy-it-now"/>
  <input type="text" name="csrf" value="csrf-token-value"/>
</form>

<iframe name="hiddenframe" style="display:none" id="hiddenframe"></iframe>
<XXX onload="loadFrame();">

Answer 3

Digamos que tenemos un sitio con Django y un Man-In-the-Middle malicioso. En el caso general, el sitio ni siquiera tendría que servir páginas http:// para que el ataque tenga éxito. En el caso de Django, probablemente deba servir al menos una página protegida por CSRF a través de http:// formato (consulte la explicación a continuación).

1. El atacante primero debe obtener un token CSRF válido sintácticamente. Para algunos tipos de token (como una simple cadena aleatoria) ella podría ser capaz de crear una. Para las fichas codificadas de Django, probablemente tendrá que obtener una de una página http:// que incluya CSRF (por ejemplo, en un campo de formulario oculto).

   El punto clave es que los tokens CSRF de Django no están vinculados a la sesión del usuario ni a ningún otro estado guardado. Django simplemente mirará para ver si hay una coincidencia entre la cookie y el valor del formulario (o encabezado en el caso de AJAX). Así que cualquier token válido servirá.

2. El usuario solicita una página a través de http:// . El atacante es libre de modificar la respuesta ya que no está cifrado. Ella hace un Set-Cookie con su token CSRF malicioso, y modifica la página para incluir un formulario oculto, y el Javascript para enviarlo, lo que hace POSTs a un punto final https:// . Esa forma, por supuesto, incluye el campo con el valor CSRF.

3. Cuando el navegador del usuario carga la respuesta, almacena la cookie CSRF especificada por el encabezado Set-Cookie y luego ejecuta el Javascript para enviar el formulario. Envía el POST al punto final https:// junto con la cookie CSRF maliciosa.

   (El hecho "desafortunado" de que las cookies establecidas en http:// se enviarán a https:// puntos finales se explica en el RFC correspondiente : "un atacante de red activo también puede inyectar cookies en el encabezado de Cookie enviado a https://example.com/ suplantando una respuesta de http://example.com/ e inyectando un encabezado Set-Cookie . El servidor HTTPS en example.com no podrá distinguir estas cookies de las cookies que se configuró en una respuesta HTTPS. el atacante de red activo podría aprovechar esta capacidad para montar un ataque contra example.com incluso si example.com utiliza HTTPS exclusivamente ".

4. Finalmente, el servidor Django recibe la solicitud POST maliciosa. Compara la cookie CSRF (establecida por el atacante) con el valor en la forma (establecida por el atacante) y ve que son iguales. Permite la solicitud maliciosa.

Por lo tanto, para evitar ese resultado, Django también verifica el encabezado del Referer (que se espera que siempre se establezca en https:// pedidos) con el encabezado del Host . Esa comprobación fallará en el ejemplo anterior porque el atacante no puede falsificar el encabezado del Referer . El navegador lo configurará en la página http:// que el atacante usó para alojar su forma maliciosa, y Django detectará la discrepancia entre eso y el punto final https:// que está sirviendo.

Answer 4

El ataque Man-In-The-Middle se explica en términos muy simplistas. Imagina que dos personas están hablando entre sí y antes de comenzar a hablar, hacen un apretón de manos antes de iniciar una comunicación de dos vías. Cuando una tercera persona comienza a analizar cómo se comunican los dos individuos (¿Cuáles son sus modales? ¿Hacen un apretón de manos especial antes de hablar entre ellos? ¿A qué hora les gusta hablar entre ellos, etc.) , la tercera persona puede moldear su comunicación hasta el punto en que puede integrarse en una conversación y actuar como mediador con las dos personas originales pensando que están hablando entre sí.

Ahora toma el concepto y baja al nivel geek. Cuando una PC, un enrutador, programas, etc. se comunican con otro nodo a la red, se produce una comunicación bidireccional mediante la autenticación, el reconocimiento o ambos. Si un tercero puede determinar la secuencia de eventos que se requieren (id de sesión, cookie de sesión, la siguiente secuencia de reconocimiento / transferencia / terminación en el tráfico, etc.), un tercero malintencionado puede reflejar su propio tráfico como un nodo legítimo y inunde el tráfico a uno de los nodos legítimos y si obtienen la secuencia correcta de eventos, el tercero malicioso se acepta como un nodo legítimo.