Come funziona questo attacco Man-In-The-Middle?

Question

IL Documentazione di Django sulla sua protezione CSRF afferma che:

Inoltre, per le richieste di HTTPS, il controllo rigoroso dei referenti viene effettuato da CSRFVIEDMIDDLEWARE.Ciò è necessario per affrontare un attacco uomo-in-the-middle possibile in HTTPS quando si utilizza una nonce indipendente di sessione, a causa del fatto che le intestazioni di HTTP 'set-cookie' sono (purtroppo) accettate dai clienti che parlano con a Sito sotto HTTPS.(Il controllo dei referenti non viene eseguito per le richieste HTTP perché la presenza dell'intestazione del referente non è abbastanza affidabile ai sensi di HTTP.)

Ho difficoltà a visualizzare come funziona questo attacco.Qualcuno potrebbe spiegare?

AGGIORNAMENTO:
La formulazione nel documento Django sembra implicare che esista un tipo specifico di attacco man-in-the-middle (che presumo porti a un CSRF di successo) che funziona con nonce indipendente dalla sessione (ma non con nonce specifico della transazione ecc. ., suppongo) e implica l'uso dell'intestazione 'Set-Cookie'.
Quindi volevo sapere come funziona quel tipo specifico di attacco.

Answer 1

.

L'attaccante può impostare il cookie CSRF utilizzando set-cookie, quindi fornire un token corrispondente nei dati del modulo post.Poiché il sito non collega i cookie della sessione ai cookie CSRF, non ha modo di determinare che il token + cookie CSRF è genuino (facendo hashing ecc. Di uno di loro non funzionerà, poiché l'attaccante può semplicemente ottenere una coppia validadal sito direttamente e usa quella coppia nell'attacco).

direttamente dal progetto Django

(ho googled for Session indipendente nonce .)

Answer 2

Ecco un Descrizione molto dettagliata di un tale attacco di mitm. Di seguito è riportato un adattamento abbreviato e semplificato:

Supponiamo che:

.
• Il sito attaccato è foo.com
• Noi (l'attaccante) possono mitm tutte le richieste
• Alcune pagine vengono servite su http (ad esempio, http://foo.com/browse < / Strong>)
• Alcune pagine vengono servite su https (ad esempio, https://foo.com/check_out < / Strong>), e quelle pagine sono protette da un cookie log-in (w / set sicuro). Si noti che questo significa che non possiamo rubare il cookie di login dell'utente.
• Tutti i moduli sono protetti confrontando un parametro modulo con il cookie CSRFTOKKen . Come notato nei documenti del Django, è irrilevante per questo attacco se siano "firmati" o solo non combinati.

prendi un token csrf valido

.
• Leggi il traffico quando gli utenti visitano http://fook.com/browse
• o, se i token sono specifici della forma, possiamo semplicemente accedere al sito con il nostro account e ottenere un token valido da http://foo.com/check_out da soli.

MITM per forzare il post controllato da attaccante alla pagina HTTPS con quel token:

Modifica una pagina Servito http (ad esempio, http://foo.com/browse < / Strong>) Per avere un modulo di invio automatico che invia a un punto finale post https (ad esempio, http: / /foo.com/check_out ). Imposta anche il loro cookie CSRF per abbinare il tuo token:

<script type="text/javascript">
  function loadFrame(){
    var form=document.getElementById('attackform');
    // Make sure that the form opens in a hidden frame so user doesn't notice
    form.setAttribute('target', 'hiddenframe');
    form.submit();
  }
</script>

<form name="attackform" id="attackform" style="display:none" method="POST" 
      action="http://foo.com/check_out">
  <input type="text" name="expensive-thing" value="buy-it-now"/>
  <input type="text" name="csrf" value="csrf-token-value"/>
</form>

<iframe name="hiddenframe" style="display:none" id="hiddenframe"></iframe>
<XXX onload="loadFrame();">

.

Answer 3

L'attacco dell'uomo-in-the-medio ha spiegato in termini molto semplicistici. Immagina che due persone stiano parlando l'una con l'altra e prima di iniziare a parlare l'una con l'altra, fanno una stretta di mano prima di avviare una comunicazione a due vie. Quando una terza persona inizia ad analizzare come i due individui come le due persone comunicano (quali sono i loro manierismi?, Fanno una stretta di mano speciale prima che parlino l'un l'altro?, A che ora a loro piace parlarsi, ecc.) , la terza persona può modellare la sua comunicazione al punto che può incorporarsi in una conversazione e agire come mediatore con le due persone originali che pensano che stanno parlando tra loro.

Ora prendi il concetto e abbassa il livello del geek. Quando un PC, un router, programmi, ecc. Comunica con un altro nodo alla rete, vi è la comunicazione bidirezionale si verifica per l'autenticazione, il riconoscimento o entrambe. Se una terza parte può determinare la sequenza di eventi richiesti (ID sessione, cookie di sessione, la prossima sequenza di riconoscimento / trasferimento / cessazione nel traffico, ecc.), Una terza parte dannosa può rispecchiare il proprio traffico come un nodo legittimo e Inonda il traffico verso uno dei nodi legittimi e se ottengono la giusta sequenza di eventi in basso, il terzo malintenzionato diventa accettato come un nodo legittimo.

Answer 4

Supponiamo di avere un sito basato su Django e un Man-In-the-Middle dannoso.Nel caso generale il sito non dovrebbe nemmeno servire http:// pagine affinché l'attacco abbia successo.Nel caso di Django, probabilmente deve servire almeno una pagina protetta da CSRF rispetto a quella normale http:// (vedi sotto per la spiegazione).

1. L'aggressore deve prima ottenere un token CSRF sintatticamente valido.Per alcuni tipi di token (come una semplice stringa casuale) potrebbe essere in grado di crearne semplicemente uno.Per i gettoni criptati di Django dovrà probabilmente prenderne uno da un http:// pagina che include CSRF (ad es.in un campo modulo nascosto).

   Il punto chiave è che i token CSRF di Django non sono legati alla sessione dell'utente o a qualsiasi altro stato salvato.Django cercherà semplicemente se esiste una corrispondenza tra il cookie e il valore del modulo (o l'intestazione nel caso di AJAX).Quindi qualsiasi token valido andrà bene.

2. L'utente richiede una pagina oltre http://.L'aggressore è libero di modificare la risposta poiché non è crittografata.Fa a Set-Cookie con il suo token CSRF dannoso e altera la pagina per includere un modulo nascosto e il Javascript per inviarlo, il che POSTs ad https:// punto finale.Tale modulo, ovviamente, include il campo con il valore CSRF.

3. Quando il browser dell'utente carica la risposta, memorizza il cookie CSRF specificato dal file Set-Cookie header e quindi esegue Javascript per inviare il modulo.Invia il POST al https:// endpoint insieme al cookie CSRF dannoso.

   (Il fatto "sfortunato" che i cookie vengano impostati http:// verrà inviato a https:// endpoint è discusso in RFC pertinente:"Un utente malintenzionato di rete attivo può anche inserire cookie nell'intestazione Cookie inviata a https://example.com/ impersonando una risposta da http://example.com/ e iniettando a Set-Cookie intestazione.Il server HTTPS su example.com non sarà in grado di distinguere questi cookie dai cookie impostati autonomamente in una risposta HTTPS.Un utente malintenzionato di rete attivo potrebbe essere in grado di sfruttare questa capacità per sferrare un attacco example.com anche se example.com utilizza esclusivamente HTTPS.")

4. Infine, il server Django riceve il malware POST richiesta.Confronta il cookie CSRF (impostato dall'attaccante) con il valore nel modulo (impostato dall'attaccante) e vede che sono gli stessi.Permette la richiesta dannosa.

Quindi, per evitare questo risultato, Django controlla anche il Referer header (che dovrebbe essere sempre impostato in https:// richieste) contro il Host intestazione.Nell'esempio precedente il controllo fallirà perché l'attaccante non può falsificare il file Referer intestazione.Il browser lo imposterà su http:// pagina utilizzata dall'aggressore per ospitare il suo modulo dannoso e Django rileverà la mancata corrispondenza tra quella e il file https:// endpoint che sta servendo.