I siti Web possono accedere ai computer in LAN / Localhost tramite il browser e come bloccarli? [duplicare]

La maggior parte dei browser non distingue tra WAN, LAN e host locale. Ciò significa che applicano le stesse politiche e restrizioni per le richieste cross-site da WAN a LAN tra diversi siti sulla WAN o tra diversi siti sulla stessa LAN.

Questo significa in particolare che gli attacchi cross-site come CSRF sono possibili, e tali attacchi vengono anche utilizzati in pratica per molti anni - vedi ad esempio L'attacco su larga scala dirotta il router attraverso il browser .

E mentre CSRF può solo causare azioni indesiderate (come cambiare le impostazioni DNS di un router) ma non essere usato da solo per estrarre dati da altri attacchi, può: se hai un sito interno che è accessibile da WebSockets è anche possibile accedervi per impostazione predefinita dall'esterno utilizzando il browser come trampolino ( Cross-Origin WebSocket ). Il sito interno dovrebbe esplicitamente controllare l'origine della richiesta per bloccare questo accesso (ad esempio, aperto e non sicuro per impostazione predefinita). Altri attacchi che rendono possibile l'exfiltration sono gli attacchi XSS contro siti interni o rebinding DNS . Inoltre, per l'exfiltration è possibile utilizzare anche impostazioni non protette dei criteri di origine incrociata ( CORS ) sui siti interni. E ci potrebbe essere più possibile usando Flash.

Prevenire questo accesso è difficile poiché la maggior parte dei browser non fa distinzioni tra siti interni ed esterni. Ciò significa che è previsto che i siti interni abbiano la stessa protezione dei siti esterni. Persino un firewall perimetrale che viene utilizzato per proteggere la LAN interna dagli attacchi esterni di solito non impedisce tale accesso poiché questi attacchi funzionano su un livello non visibile alla maggior parte dei firewall.

Un modo per limitare tale accesso è utilizzare più browser (o profili), uno per interni e uno per siti esterni. L'accesso potrebbe essere limitato consentendo l'accesso a Internet solo tramite un proxy esplicito: un browser avrà il proxy configurato per tutti i siti e potrà quindi accedere solo a siti esterni, a condizione che il proxy non consenta l'accesso ai siti interni. L'altro browser non ha proxy configurato e può quindi interno ma nessun sito esterno. Questa separazione rigorosa blocca l'accesso tra siti esterni e interni attraverso il browser. Ma probabilmente ha un impatto sull'usabilità nella maggior parte degli ambienti.

While browsing internet, can websites execute code through my browser that access websites or services that are hosted on Localhost or LAN?

Ci sono alcune buone informazioni su DNS rebinding, CSRF, ecc. in altre risposte. Tuttavia, sono sorpreso che nessuno abbia menzionato la scansione di rete. JavaScript può essere utilizzato per eseguire la scansione dell'intera rete locale e determinare quali porte sono aperte su quali host.

Ecco un esempio di sito Web che esegue questo: link

Tieni presente che un sito web potrebbe farlo senza la tua autorizzazione o conoscenza.

Inoltre, se stai eseguendo servizi locali (es. redis, memcached, elasticsearch), spesso possono essere attaccati anche dal browser, come mostrato in questo post: link

I dati possono essere scritti su questi servizi, ma CORS impedisce di leggere i dati da essi, quindi è qui che arrivano gli attacchi di rebinding DNS.

Also, can data from intranet websites/services be scraped/hacked/stolen through code that is run by remote site through my web-browser?

Come sopra, dipende dalla politica CORS impostata dal server web di destinazione. Questo può essere aggirato con il rebinding DNS.

Do modern web browsers protect from these kind of attacks and how?

Non proprio; come altri hanno già detto, il browser non distingue realmente la WAN dalla LAN, né dovrebbe necessariamente farlo. Mentre CORS aiuta, abbiamo visto che può essere bypassato con il rebinding DNS.

How to isolate Localhost and Intranet access from browser?

L'unica vera soluzione è disabilitare tutto il codice JavaScript non attendibile. L'estensione NoScript è disponibile per i principali browser ed è abbastanza configurabile.

Suppongo che potresti anche tentare di separare il tuo PC dal resto della rete, e potrebbe esserci un modo (con iptables) per impedire al tuo browser di accedere ai servizi locali. Tuttavia, sospetto che sarà noioso.

Sì, i siti e i servizi scorrono via LAN o localhost può (a volte) essere accessibile tramite un utente malintenzionato nel browser. Oltre agli errori nel browser menzionati da Cybernard, ci sono altri (molto più comuni) attacchi che lo rendono possibile.

Ricorda che il javascript dannoso viene eseguito nel browser e quindi può attaccare tutto ciò che il tuo browser può raggiungere: questo include localhost e la tua LAN. Spetta alle applicazioni lì per rifiutare richieste elaborate.

DNS Rebinding Attacks

In un attacco di rebinding DNS , l'utente malintenzionato utilizza un nome host che farà riferimento a due indirizzi IP diversi. In primo luogo, farà riferimento al loro server e caricheranno una pagina dannosa contenente javascript da quel server. Il javascript attenderà e quindi farà un'altra richiesta allo stesso hostname, ma nel frattempo il server DNS avrà cambiato l'indirizzo IP in uso da quel nome host a localhost o un IP sulla LAN. Poiché hostname rimane lo stesso , il javascript dannoso non ha problemi ad accedere alla risorsa locale e può leggere i dati dal tuo localhost o dalla tua LAN.

Questa non è una preoccupazione teorica: Tavis Ormandy ha appena trovato una vulnerabilità nel client Transmission BitTorrent . È stato utilizzato per attacco router con impostazioni predefinite .

Alcuni server DNS (compresi quelli integrati in alcuni router) offrono protezione contro questo non accettando IP "locali" (RFC1918 e localhost) nelle risposte da Internet.

Contrassegno per richiesta cross-site

Se l'autore dell'attacco desidera solo cambiare stato sulla tua webapp e l'applicazione è vulnerabile a Cross-Site Richiedi falsi (CSRF), quindi possono inoltrare richieste a quel sito senza nemmeno poter leggere il contenuto delle pagine. CSRF è nella Top 10 di OWASP, quindi non si tratta di un errore insolito.

Impostazioni CORS errate

Le applicazioni che utilizzano CORS per consentire le richieste di origine incrociata potrebbero essere errate -configurato e consente le richieste di origine incrociata provenienti da siti dannosi in esecuzione nel browser. Sebbene non siano esclusivi della tua LAN o localhost, possono comunque esserne interessati.

Domanda 1: Durante la navigazione su Internet, i siti web possono eseguire codice tramite il mio browser che acceda a siti Web o servizi che sono ospitati su Localhost o LAN?

Sì, non facilmente e solo attraverso una sorta di hacking.

Gli hacker sono molto intelligenti e lavorano costantemente per sfruttare le vulnerabilità nei browser web. Se colpiscono il tuo browser con un giorno zero, potrebbero molto bene iniettare il codice e farlo eseguire. Così facendo leva su un accesso sempre maggiore a ogni tentativo. La maggior parte degli hacker inietterà un virus desktop remoto in modo che possano vedere e interagire con il desktop, ma non sempre.

Domanda 2: Inoltre, i dati di siti Web / servizi intranet possono essere cancellati / hackerati / rubati tramite codice gestito da un sito remoto tramite il mio browser web?

Sì, non facilmente e solo attraverso una sorta di hacking.

Domanda 3: i moderni browser Web proteggono da questo tipo di attacchi e in che modo?

Centinaia, migliaia o più di ore di test sull'uomo. Avere team di ricerca sulla sicurezza colpire ogni browser in ogni modo possibile per vedere quali interruzioni. Quindi facendoli riferire su di essi in modo che il team del browser possa ripararli. Inoltre sponsorizzano eventi durante le convenzioni di hacking in cui vengono pagati i soldi reali per gli exploit. Se l'exploit è abbastanza buono, può portare 10.000 o anche un milione di dollari per il ricercatore o il team che porta l'hacker.

Hanno persino dei fuzzers, che lanciano dati casuali sul browser web per vedere se qualcosa si rompe o si comporta in modo inaspettato.

I giorni zero ad alto livello stanno diventando più rari, ma le persone molto intelligenti stanno ancora lavorando su di loro. I tesori di exploit zero day sono in balia del male facendo gruppo di hacker disposto a vendere se il prezzo è giusto.

Domanda 4: Come isolare l'accesso Localhost e Intranet dal browser?

• Software sandbox e macchina virtuale
• Uso delle ultime versioni di tutto.
• firewall Non caricare estensioni non testate e non provate nel browser.
• rilevatori di anti-virus e rootkit
• IDS

Finisco questa informazione spaventosa con un po 'di sanità mentale.

Tutti i browser Web sono stati sottoposti a test approfonditi e hanno costantemente aggiornato il loro codice. Mentre la risposta è SI, possono entrare, è incredibilmente difficile ora un giorno. Solitamente ci vogliono gruppi di persone per trovare e sfruttare le vulnerabilità del browser Firefox, Chrome e Edge. Spesso ci vogliono mesi di ricerca dedicata per trovare anche un punto debole. Anche allora possono volerci altri mesi per trasformarlo in un exploit di lavoro. Nel frattempo i whitehats, bravi ragazzi, sono sempre più vicini a trovare la stessa cosa e risolvere il problema. Questo può annullare mesi di duro lavoro per gli hacker. Non è più un compito banale.