Rischi associati all'iniezione di contenuto HTTP?

2

Sono curioso dei rischi associati all'iniezione di contenuto HTTP, in cui un ISP inietta il contenuto di pagine a cui si accede tramite connessioni non HTTPS.

Alcuni esempi:

  1. link

  2. link

Ti sto chiedendo in particolare di situazioni in cui:

  1. L'iniezione viene eseguita solo contro le connessioni HTTP. L'ISP non sta falsificando i certificati SSL.

  2. Il contenuto inserito non è dannoso. Ad esempio, un banner che elenca i minuti liberi rimanenti su una connessione WiFi dell'hotel.

L'atto di introdurre questo contenuto introduce ulteriori vettori di attacco diversi da quelli normalmente associati all'uso di HTTP?

    
posta 5lihein1fe36bgqc 03.06.2015 - 15:10
fonte

3 risposte

1

Considerando che il codice che iniettano può essere qualsiasi cosa, si dovrebbe supporre che ci siano dei rischi. Forse il loro codice ha una vulnerabilità che consente l'iniezione. Forse oscura elementi importanti nella pagina. Forse fa riferimento a una risorsa esterna (es .: JavaScript) di minore sicurezza. Chissà? Sicuramente mi sembra un rischio.

Ci sono altri rischi a cui sei esposto indipendentemente dall'iniezione. Ad esempio, probabilmente stanno fornendo un DNS personalizzato di comportamento sconosciuto. Quindi sei a loro rischio per la sicurezza DNS.

In effetti, come sai che stai usando il router WiFi dell'hotel? In generale non è possibile.

È considerato negativo utilizzare router WiFi aperti.

L'uso di una VPN (io uso PIA ) è generalmente considerato una strategia sicura.

    
risposta data 03.06.2015 - 17:42
fonte
0

Un attaccante attivo che si posiziona per alterare il tuo traffico di rete può fare tutto ciò che l'ISP può fare al tuo traffico HTTP. In questo senso, un MITM (il tuo ISP) che inserisce il contenuto in una pagina non altera la capacità di un altro MTIM (un utente malintenzionato) di leggere o scrivere il tuo traffico.

Tuttavia, la preoccupazione principale sembra essere rappresentata dagli attacchi passivi che vengono miniati dal servizio da parte dei meccanismi client-side. Dal tuo primo articolo:

Even if Comcast doesn't have any malicious intent, and even if hackers don't access the JavaScript, the interaction of the JavaScript with websites could "create" security vulnerabilities in websites, Schoen said. "Their code, or the interaction of code with other things, could potentially create new security vulnerabilities in sites that didn't have them," Schoen said in a telephone interview.

Come esempio banale, supponiamo che un sito consumi JSON fornito come parametro URL come http://example.com/show?json={"foo":5,...} . Il sito utilizza la funzione JavaScript JSON.parse per analizzare il JSON. Nel frattempo, uno sviluppatore sconsiderato dell'ISP ha incluso la riga JSON.parse = function(e){return eval("("+e+")")}; nel loro script MITM (perché JSON.parse non è supportato nei browser più vecchi, e il suo comportamento è fondamentalmente un sottoinsieme di eval comunque).

Ciò consentirebbe ovviamente a un utente malintenzionato di inviarti un link come http://example.com/show?json=sendToBadGuys(document.cookie) a un risultato potenzialmente disastroso. L'attaccante non ha bisogno di essere in grado di intercettare il tuo traffico; l'autore dell'attacco deve solo essere in grado di farti fare clic su un link . Il sito ha ricevuto una nuova vulnerabilità di sicurezza dal proprio ISP.

Naturalmente, nessuno è abbastanza sciocco da sovrascrivere completamente JSON.parse con eval (o, comunque, è il sogno), ma questo esempio dimostra che l'abilità del MITM di intromettersi con l'ambiente JavaScript è chiaramente pericolosa cosa, anche se ben intenzionata.

Inoltre, come preoccupazione completamente separata, qualsiasi informazione che il MITM ben intenzionato include potrebbe essere letta da un MITM malevolo. Ad esempio, se il tuo banner dell'hotel aggiunge informazioni personali come "Tempo rimanente per John Smith nella stanza 123: dieci minuti" a tutte le tue pagine Web HTTP, ovviamente è anche una preoccupazione.

    
risposta data 03.06.2015 - 17:58
fonte
0

risks associated with HTTP content injection ...I'm specifically asking about situations where ...the injected content is non malicious

Quindi stai chiedendo in effetti se può accadere qualcosa di brutto quando si iniettano contenuti che non sono malevoli da soli. Le cose più ovvie sono:

  • Iniezioni rotte, che non sono destinate a essere dannose ma introducono involontariamente nuovi vettori per attacchi XSS o simili. Non sono a conoscenza di un esempio reale di iniezioni HTML, ma alcuni ISP eseguono un simile "adattamento del contenuto" quando l'utente tenta di accedere a siti inesistenti e questo in realtà ha portato a exploit .
  • L'iniezione di tracker e annunci di terze parti può causare problemi con gli annunci e i tracker senza un'iniezione, ad esempio il malvertising ecc.

Meno ovvio è che l'iniezione potrebbe semplicemente andare male o interagire male con il sito e quindi causare un cambiamento nel comportamento del sito. Alcuni esempi stanno ridefinendo le funzioni Javascript utilizzate dall'utente, ridefinendo gli id degli elementi HTML che causano un'interazione non voluta con CSS o Javascript ecc. E poi ci sono siti fragili che sono già in qualche modo danneggiati ma che vengono elaborati dai browser (molto tolleranti) Comunque. Questi siti potrebbero quindi comportarsi inaspettatamente in modo diverso.

    
risposta data 03.06.2015 - 18:12
fonte

Leggi altre domande sui tag