Sul livello applicazione, il tuo browser non ha nozioni di indirizzi IP interni ed esterni. Quindi qualsiasi sito web può semplicemente dire al tuo browser di richiedere una risorsa dalla tua rete interna. Questo non verrebbe bloccato dal momento che per il browser è solo una normale richiesta di cross-origine. Nota che il sito richiedente non sarà in grado di leggere qualsiasi cosa, potrebbe solo concludere che qualcosa è lì.
Ad esempio, un sito web potrebbe provare a scoprire se il router ha un'interfaccia web a 192.168.1.1 utilizzando uno snippet come questo:
<img src="http://192.168.1.1/favicon.ico"onload="alert('Yay')" onerror="alert('No')">'
Allo stesso modo, un sito web può farti richiedere risorse da indirizzi IP interni (e all'indirizzo quasi porte arbitrarie) e misurare i tempi di risposta per concludere che esiste un servizio in esecuzione: ad esempio, se una richiesta a http://localhost:8080 ha un tempo di risposta breve, potresti eseguire un proxy locale o simile.
Se si sovrappongono tali richieste, si può in qualche modo fare in modo che il browser conduca una scansione di rete di base e inferisca su IP, nomi di host e servizi esistenti.
Questa idea è anche usata per attacchi reali. Anche se l'interfaccia del router non è accessibile dall'esterno, un utente malintenzionato esterno potrebbe eseguire un attacco come il recente exploit di esecuzione di codice arbitrario del router Netgear inducendoti a visitare un sito Web preparato che ti tu conduci tu stesso l'attacco inviando una richiesta appositamente predisposta all'interfaccia del router. (Essenzialmente un attacco CSRF sulla intranet.)
Un modo per mitigare il rischio di accesso alla intranet è il modulo ABE (Application Boundaries Enforcer) dell'estensione NoScript che può essere configurato per bloccare particolari host.
Un utente malintenzionato può davvero non leggere alcun contenuto?
Spesso possono leggere il contenuto di un sito intranet conducendo un attacco DNS rebinding . Supponiamo che l'interfaccia del router sia accessibile a 192.168.1.1/info.cgi . In un attacco di rebinding DNS, l'attaccante ti fa visitare attacker.com che per prima cosa punta all'IP del proprio server, carica alcuni Javascript, quindi punta a 192.168.1.1 . Quando il Javascript richiede attacker.com/info.cgi , viene invece risolto nell'interfaccia del router e lo script è in grado di leggere il contenuto della risposta. Ciò non viola la politica dell'origine stessa perché tutte le richieste sono sulla stessa origine (il dominio attacker.com ), sebbene la voce DNS cambi in background. (Come contromisura, i siti devono verificare che l'intestazione Host contenga il nome IP o il nome intranet, ma molti router non lo fanno.)