JavaScript Injection usa Man in the Middle Attack

L'ISP (qui, l'hotspot WiFi) è ciò che ti offre le pagine. Ovviamente è banale che un ISP legga il traffico non protetto:

Consideriamoorauncasoincuil'inviodellecredenzialièprotettoconHTTPS(quindil'ISPnonpuòannusarledirettamentedalfilo),malapaginadiaccessoHTTPScaricaunoscriptnonprotetto,helper.js.L'ISPpuòiniettarequalsiasicomportamentoinquelloscriptnonHTTPSprimadiservireinfineloscriptalbrowser.Adesempio,l'ISPpuòinserireleistruzioni," Quando questa pagina invia le credenziali, invia una copia di esse a evil.example.com . " Il diagramma seguente mostra richieste e risposte sicure in richieste / risposte verdi e non sicure in altri colori:

Quandoiltuobrowserrichiedehelper.jssuHTTP,l'ISPdannosorispondeconunarisorsaconilcontenutosbagliato.Iltuobrowsernonhaideadicomedovrebbeapparirehelper.jse,senzaalcunamisuradiconvalidadell'integrità(comeHTTPS),ilbrowsernonhaideadinullachenonva.Iltuobrowserpresupponechesiastatocorrettamentepubblicatohttp://tmail.com/helper.js,perchéèquellochehachiestoel'ISPharestituitounarispostasenzaalcunreclamo(adesempio,larispostaeraun200HTTPper/helper.js).Ilfattocheciòcheiltuobrowserhaèdiversodaciòcheilveroserverhainviatoètotalmenteirrilevante,perchéiltuobrowsernonhamododirilevarechequestadifferenzasièverificata.

Inbaseaituoicommenti,sembrachetupossapensaredimodificareunarisorsasoloreindirizzandoilbrowseraun'altrarisorsa.QuestononècorrettoConsideraMarioilbrowser,Iggyl'ISPedueserver,AliceeMallory.

Perprimacosa,considerailcasoonesto:

• BobvuoleconoscereilcibopreferitodiAlice.

  • BobdiceaIggy,"Ehi, Iggy, per favore invia un GET /favoritefood a alice.com ."
  • Iggy chiede ad Alice del suo cibo preferito. Alice gli dice "Pizza, ma senza cipolle, perché odio le cipolle".
  • Iggy torna da Bob e dice "Ehi, ho la risposta per il tuo GET /favoritefood da alice.com ! Dice che adora la pizza, ma non le cipolle."

Ora consideriamo un caso disonesto:

• Bob vuole conoscere il cibo preferito di Alice.

  • Bob dice a Iggy, "Ehi, Iggy, per favore invia un GET /favoritefood a alice.com ."
  • Iggy torna da Bob e dice " 301 Moved Permanently - chiedi a Mallory del cibo preferito di Alice"
  • Bob invia quindi Iggy a GET /favoritefood da mallory.com . È una risorsa diversa, e Bob conosce è una risorsa diversa da quella che aveva originariamente richiesto.

In questo caso, la barra degli indirizzi del browser sarà diversa da quella in cui è stato digitato originariamente: mallory.com/favoritefood anziché alice.com/favoritefood .

Consideriamo ora questo caso:

• Bob vuole conoscere il cibo preferito di Alice.

  • Bob dice a Iggy, "Ehi, Iggy, per favore invia un GET /favoritefood a alice.com ."
  • Iggy chiede ad Alice del suo cibo preferito. Alice gli dice "Pizza, ma senza cipolle, perché odio le cipolle".
  • Iggy ritorna da Bob e dice "Ehi, ho la risposta per il tuo GET /favoritefood da alice.com ! Dice che adora mangiare tante e tante cipolle."

Non ci sono altre risorse coinvolte. http://alice.com/favoritefood è l'unica risorsa da recuperare qui; Iggy ha semplicemente mentito su quali fossero i contenuti della risorsa. Bob non ha modo di scoprire che Iggy sta mentendo, perché non esiste un sistema di convalida dell'integrità.

Un ultimo tentativo di spiegazione: supponiamo che l'ISP sia onesto, ma erroneamente ha invertito un singolo bit durante la consegna del contenuto del file HTML. Sicuramente non ti aspetteresti che un tale errore causi il caricamento della pagina web in un dominio diverso. Supponiamo ora che l'ISP onesto abbia erroneamente invertito due bit invece di uno solo: ancora una volta, un tale errore non avrebbe mai causato il cambiamento del percorso del dominio o delle risorse. Ora supponiamo che l'ISP abbia capovolto duemila bit per errore onesto (forse l'ISP ha commutato un errore in qualche posto, o il router WiFi è stato colpito dai raggi cosmici): ancora una volta, non c'è bisogno che il dominio cambi. Ora supponiamo che il cambiamento sia stato fatto malignamente invece che per errore: ancora una volta, il cambiamento di intenti non causa alcun cambiamento in ciò che sta realmente accadendo. Il percorso e l'origine delle risorse, come identificati nella barra degli indirizzi del browser, rimangono invariati, mentre l'ISP è libero di modificare il contenuto della risorsa (onestamente o in modo disonesto) senza rilevamento.

Presumo che il modulo di accesso su tmail.com verrà inviato con https. Altrimenti puoi leggere la semplice password con un pacchetto di ispezione.

Il tuo browser carica una pagina web da tmail.com. Il proprietario del wifi può aggiungere un JavaScript in questa pagina. Questo script registrerà tutto ciò che digiti nel modulo di accesso del provider di posta e lo memorizzerà da qualche parte.

Will URL still remain the tmail.com when I am accessing this or will it change?

Sì, sembrerà tutto uguale. Ma il codice sorgente della pagina contiene JavaScript aggiuntivo.

Where (application layer/network layer) and how (download the web page or modify network layer data) exactly the attacker will make the changes to succeed?

Nel livello applicazione cambierà la pagina web.

Aggiorna

Per una migliore comprensione potresti voler ottenere mitmproxy.org e utilizzare replacement strumento:

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

Questo aggiungerà un JavaScript a tutte le pagine html che passano attraverso.