Inyección de JavaScript usando Man in the Middle Attack

El ISP (aquí, el punto de acceso WiFi) es lo que le entrega las páginas. Por supuesto, es trivial para un ISP leer tráfico no seguro:

ConsideremosahorauncasoenelqueelenvíodecredencialesestáprotegidoconHTTPS(porloqueelISPnopuededetectarlosinmediatamente),perolapáginadeiniciodesesióndeHTTPScargaunscriptnoseguro,helper.js.ElISPpuedeinyectarcualquiercomportamientoenesescriptquenoseaHTTPSantesdequefinalmentesirvaelscriptalnavegador.Porejemplo,elISPpuedeinyectarlasinstrucciones," Cuando esta página envíe credenciales, envíe una copia de ellas a evil.example.com . " El diagrama a continuación muestra las solicitudes y respuestas seguras en verde y las solicitudes / respuestas inseguras. en otros colores:

Cuandosunavegadorsolicitahelper.jsatravésdeHTTP,elISPmaliciosorespondeconunrecursoquetieneelcontenidoincorrecto.Sunavegadornotieneideadecómodeberíaserhelper.js,ysinningunamedidadevalidacióndeintegridad(comoHTTPS),elnavegadornotieneideadequealgoestémal.Sunavegadorasumequesehaservidocorrectamentehttp://tmail.com/helper.js,porqueesoesloquesolicitóyelISPledevolvióunarespuestasinningunaqueja(porejemplo,larespuestafueHTTP200para/helper.js).Elhechodequeloquesunavegadorobtuvoesdiferentedeloqueelservidorrealenvióestotalmenteirrelevante,yaquesunavegadornotieneformadedetectarqueocurrióestadiferencia.

Segúnsuscomentarios,parecequepiensaquelamodificacióndeunrecursosolosepuedehacerredireccionandoelnavegadoraotrorecurso.Estoesincorrecto.ConsidereBobelnavegador,IggyelISPydosservidores,AliceyMallory.

Primero,consideraelcasohonesto:

• BobquieresaberlacomidafavoritadeAlice.

  • BoblediceaIggy:"Oye, Iggy, envía un GET /favoritefood a alice.com ".
  • Iggy le pregunta a Alice sobre su comida favorita. Alice le dice: "Pizza, pero sin cebollas, porque odio las cebollas".
  • Iggy regresa con Bob y dice "¡Oye, tengo esa respuesta para tu GET /favoritefood de alice.com ! Ella dice que le encanta la pizza, pero no las cebollas".

Ahora consideremos un caso deshonesto:

• Bob quiere saber la comida favorita de Alice.

  • Bob le dice a Iggy: "Oye, Iggy, envía un GET /favoritefood a alice.com ".
  • Iggy regresa con Bob y le dice: " 301 Moved Permanently ; pregúntale a Mallory sobre la comida favorita de Alice"
  • Bob luego envía a Iggy a GET /favoritefood desde mallory.com en su lugar. Es un recurso diferente, y Bob sabe es un recurso diferente del que solicitó originalmente.

En este caso, la barra de direcciones del navegador sería diferente de la que escribiste originalmente: mallory.com/favoritefood en lugar de alice.com/favoritefood .

Ahora considere este caso en su lugar:

• Bob quiere saber la comida favorita de Alice.

  • Bob le dice a Iggy: "Oye, Iggy, envía un GET /favoritefood a alice.com ".
  • Iggy le pregunta a Alice sobre su comida favorita. Alice le dice: "Pizza, pero sin cebollas, porque odio las cebollas".
  • Iggy regresa con Bob y dice "¡Oye, tengo esa respuesta para tu GET /favoritefood de alice.com ! Ella dice que le encanta comer muchas y muchas cebollas".

No hay otros recursos involucrados. http://alice.com/favoritefood es el único recurso que se busca aquí; Iggy simplemente mintió acerca de cuáles eran los contenidos del recurso. No hay forma de que Bob detecte que Iggy está mintiendo, porque no hay un sistema de validación de integridad en su lugar.

Un último intento de explicación: supongamos que el ISP es honesto pero equivocadamente cambió un solo bit al entregar el contenido del archivo HTML. Seguramente usted no esperaría que tal error cause que la página web se cargue bajo un dominio diferente. Ahora suponga que el ISP honesto volcó erróneamente dos bits en lugar de uno solo: una vez más, tal error nunca haría que el dominio o la ruta de recursos cambiaran. Ahora supongamos que el ISP volcó dos mil bits por un error honesto (tal vez el ISP tiene un interruptor defectuoso en algún lugar, o el router WiFi fue alcanzado por rayos cósmicos): nuevamente, no es necesario que cambie el dominio. Ahora supongamos que el cambio se realizó maliciosamente en lugar de por error: nuevamente, el cambio en la intención no causa ningún cambio en lo que realmente está sucediendo. La ruta y el origen del recurso, tal como se identifican en la barra de direcciones del navegador, se mantienen sin cambios, mientras que el ISP es libre de cambiar el contenido del recurso (de manera honesta o deshonesta) sin ser detectado.

Supongo que el formulario de inicio de sesión en tmail.com se enviará con https. De lo contrario, puede leer la contraseña simple con un inspector de paquetes.

Su navegador carga una página web desde tmail.com. El propietario de wifi puede agregar un JavaScript en esta página. Esta secuencia de comandos registrará lo que escriba en el formulario de inicio de sesión del proveedor de correo y lo almacenará en algún lugar.

  

¿Seguirá siendo la URL tmail.com cuando acceda a esto o cambiará?

sí, todo se verá igual. Pero el código fuente de la página contiene JavaScript adicional.

  

¿Dónde (capa de la aplicación / capa de red) y cómo (descargar la página web o modificar los datos de la capa de red) exactamente el atacante hará que los cambios tengan éxito?

En la capa de aplicación cambiará la página web.

Actualizar

Para una mejor comprensión, le gustaría obtener mitmproxy.org y usar reemplazo herramienta:

:~q:</html>:<script>alert('hi')</script></html>

Esto agregará un JavaScript a todas las páginas html que pasan.