Configura Firefox contro il reindirizzamento 302 malevolo da una risorsa immagine incorporata?

1

Oggi il mio amico ha dimostrato un simile attacco.

Uso RenRen, un sito di social network in un modo molto simile a Facebook in Cina. E ho visto un articolo che ha scritto. In realtà c'è solo una "immagine" incorporata in questo articolo, come questa:

<img src="http://somesite.org/x.php" ... >

Quando un browser tenta di richiedere questo URL, le intestazioni HTTP sono un reindirizzamento temporaneo 302 e la destinazione è la pagina di disconnessione di RenRen, ad esempio:

www.renren.com/logout.do 

So che consentire a un'immagine del genere esistente in un articolo pubblicato è il fallimento del programmatore di RenRen. Ma invece di dire loro di risolvere il problema, voglio configurare il mio browser in modo che sia contro di esso. Alcuni browser come Safari, come noto, sono resistenti a un simile attacco, probabilmente perché esegue il controllo del tipo MIME. Ma non ho trovato una soluzione simile in Firefox, nemmeno il plugin giusto. Sembra che NoScript con la configurazione appropriata farà, ma non sono ancora sicuro.

Quindi mi piacerebbe sapere come classificare questo tipo di attacchi e come prevenirlo ---- non solo per Firefox ...

    
posta Lucifer Orichalcum 20.08.2013 - 12:33
fonte

4 risposte

2

non puoi difendere in modo proattivo contro questa classe di attacchi. Prendere in considerazione:

  • il file sorgente contiene un URL http.

    • Non puoi sapere se è dannoso o meno.
    • Non vuoi impedire che venga caricato (bloccherebbe l'attacco - ma renderebbe inutilizzabili diversi siti di archivi di immagini legittimi).
  • devi quindi richiedere quell'URL.

    • l'azione di logout viene attivata su request , quindi quando il browser riceve una pagina HTTP / 200 OK text/html che dice "Sei stato disconnesso correttamente", anche se rifiuta per visualizzarlo, il comando è già completato .

Puoi organizzare le cose in modo che l'attacco fallisca , comunque.

Potresti eliminare tutti gli identificativi di sessione da qualsiasi richiesta non appena tocchi un reindirizzamento , in modo che la pagina di disconnessione non ti riconosca più. Questo potrebbe essere fattibile con un'estensione per Firefox. In questo modo, avresti:

lucifer -> renren:   get me the message
renren  -> lucifer:  there is an image here
lucifer(*) -> somesite: get me the image
somesite-> lucifer:  go to renren/logout
(the request thread drops the cookie jar and becomes anonymous)
anonymous->renren:   get me the logout
renren->anonymous:   logout who? Error. Cannot logout.
(the request thread expires)

(*) in realtà il tuo ID cookie con renren è non inviato a somesite , poiché è probabile in un altro dominio.

Ciò potrebbe causare malfunzionamenti in alcune applicazioni AJAX e possibilmente implementazioni OAuth; Dovrei controllare questo.

    
risposta data 20.08.2013 - 14:09
fonte
0

Un tale tipo di attacco è, per quanto ne sappia, classificato come un attacco CSRF (Cross-Site Request Forgery) e, in generale, non può essere difeso.

Non conosco un modo per configurare Firefox per bloccare questo tipo di attacchi, ma c'è (come hai detto) NoScript, che viene fornito con una bella funzionalità, ABE (Application Boundaries Enforcer) che ti permette di specificare quale i siti Web possono accedere a quali altri siti.

Puoi configurare ABE tramite Impostazioni - > Avanzate: > ABE. Qui puoi selezionare il set di regole USER, in cui puoi definire le regole che vuoi applicare.

Un esempio per bloccare tutti gli accessi che provano ad includere risorse ( <img> , <script> ...) da renren.com e tutti i siti secondari, che non hanno avuto origine in renren.com o in un sito secondario :

Site .renren.com
Accept from .renren.com
Deny INCLUSION

Uno svantaggio di questo modo è che, se renren.com fornisce mezzi per incorporare immagini in altri siti web, anche questo sarebbe bloccato, ma probabilmente potrebbe essere risolto utilizzando Anonymize , a tale scopo. Dall'altro lato, se vuoi essere ancora più restrittivo, puoi lasciare INCLUSION , il che comporterà anche il blocco dei link e il reindirizzamento nei link su cui hai fatto clic.

La differenza tra le azioni Deny e Anonymize è che l'azione Deny blocca completamente la richiesta mentre l'azione Anonymize spoglia l'intestazione Autorizzazione e l'intestazione Cookie e trasforma tutte le richieste diverse da GET (cioè POST, HEAD, PUT ...) in richieste GET senza data. Il risultato è che il sito web (di solito) non può associare la richiesta a una sessione e /logout.do non può terminare la sessione, perché non sa a quale sessione avrebbe dovuto finire, ma le immagini sono incorporate in altre i siti web che non richiedono una sessione di lavoro verranno visualizzati. Uno svantaggio dell'azione Anonymize è che non mostra mai una barra delle informazioni che NoScript abbia anonimizzato la richiesta, ma lo anonima in modo silente, quindi se stai usando Anonymize e qualcosa non funziona come dovrebbe , prova a utilizzare Deny , che mostrerà una barra delle informazioni nella parte superiore dello schermo se blocca qualcosa.

Se stai utilizzando un servizio diverso per accedere a renren.com come MSN, 360.cn, 189.cn o Baidu (elencati nell'ordine di apparizione su renren.com), quindi, con il solo blocco INCLUSION potrebbe (piuttosto improbabile) essere che devi mettere una clausola Accept (esempio: Accept from openapi.baidu.com ) anche per il sito corrispondente, se blocchi tutto allora tu dovrà metti uno nel set di regole.

Ulteriori informazioni su ABE sono disponibili qui .

    
risposta data 20.08.2013 - 15:38
fonte
0

Questa è una vulnerabilità di Cross-Site Request Forgery (CSRF) sulla www.renren.com sito web. Dovrebbero aver implementato la pagina logout.do per disconnettere l'utente solo quando viene effettuato un requst POST contenente un token nel payload che convalidano per garantire che la richiesta di logout provenga da un utente sul proprio sito.

Questo dovrebbe essere controllabile dall'utente disabilitando i cookie di terze parti . Quando disabiliti i cookie di terze parti in Chrome impedisce al dominio di terze parti di leggere il cookie, quindi la pagina www.renren.com/logout.do non sarà in grado di disconnetterti a meno che non sia richiesta in una nuova finestra o scheda. Non sono stato in grado di trovare una risposta chiara se Firefox consente la lettura di cookie di terze parti quando accetta i cookie di terze parti sono disabilitati , ma puoi provare questo e vedere se l'exploit <img src="http://example.org/x.php" /> fallisce.

    
risposta data 21.08.2013 - 16:14
fonte
-2

Aggiungi

127.0.0.1 somesite.org

Al tuo file hosts o bloccalo sul firewall o sul proxy.

    
risposta data 20.08.2013 - 13:03
fonte

Leggi altre domande sui tag