Invia un attacco CSRF con un referente di intestazione specifico?

Naviga le tue risposte
2

C'è un modo per aggirare una protezione CSRF del referrer e forzare www.attacker.com a inviare una richiesta POST a www.victim.com con l'intestazione che mostra come "referer: link "?

Ad esempio, lo script sottostante può cambiare il referrer dalla pagina del browser, ma un utente malintenzionato può inviare una richiesta che mostra un dominio referrer diverso da www.victim.com. 

    <script>
          delete window.document.referrer;
            window.document.__defineGetter__('referrer', function () {
                return "https://www.victim.com";
            }); 
alert(document.referrer)
    </script>

link

So che ci sono modi per aggirare alcune protezioni CSRF del referrer Ad esempio, mostrando le richieste del referrer con vuoto o vuoto, ma se l'applicazione web rifiuta referrer vuoti o vuoti e un "dominio o sottodominio specifico" è necessario per elaborare la richiesta POST.

Sarebbe possibile bypassare questa protezione da un dominio esterno?

    
posta pancho 03.06.2016 - 01:21
fonte

2 risposte

3

fai riferimento alla sezione "Controlli delle intestazioni standard" in questa pagina:

link

A mia conoscenza, le intestazioni dei referrer non possono essere modificate se non ci sono difetti xss. Le richieste Ajax non sono inoltre autorizzati a modificare l'intestazione del referrer come indicato da qualcuno nei commenti su questo thread:

utilizzo di CSRF in richiesta Ajax tramite errore XSS

    
risposta data 03.06.2016 - 05:32
fonte
4

Referer è considerato un intestazione speciale (come "Host") e non può essere impostato all'interno del browser. Quindi il massimo che puoi fare con alcuni trucchi è renderlo vuoto, ma non indicare altro lato.

Ovviamente potresti utilizzare altri strumenti per creare richieste elaborate con la tua intestazione Referer . Ma in questo caso tu (come attaccante) non hai accesso ai cookie rilevanti per il sito di destinazione, quindi non funzionerebbe nemmeno come attacco CSRF.

    
risposta data 03.06.2016 - 03:56
fonte

Leggi altre domande sui tag

Perché non abbiamo bisogno di un handshake WPA su un attacco MiTM spoofing ARP? I certificati SSL / TLS gratuiti sono affidabili? I fornitori di Cert possono trafficare? [duplicare]