Perché posso leggere la risposta a questo attacco CSRF?

Question

Perché posso leggere la risposta a questo attacco CSRF?

#1 da (5 voti)
#2 da (3 voti)
#3 da (2 voti)

2

Ho un sito web www.foo.com:8002 che ho risolto a 127.0.0.1:8002 nel mio file hosts. Ne ho un altro (il sito principale) in esecuzione su localhost: 80

In www.foo.com:8002 la pagina appare come

<form name="myform" action="http://localhost/bar" method="post">
  <input type="hidden" name="some" value="value" />
</form>
<script> document.myform.submit() </script>

Mi aspettavo che la richiesta passasse e il browser (Chrome) non leggesse la risposta poiché viola la stessa politica di origine. Tuttavia, si scopre che il browser riceve la risposta e visualizza i contenuti perfettamente bene. Com'è possibile?

web-browser csrf same-origin-policy

posta Jarrod Everett 28.08.2012 - 00:09

fonte

3 risposte

3

Questo è il punto di CSRF, il tuo browser effettua la richiesta come se fosse stata avviata da un utente. In una situazione di attacco CSRF reale, GET o POST si troveranno all'interno di iframe invisibile, in modo che la vittima non sia consapevole di essere stata compromessa.

In questo caso il codice JavaScript o ActionScript dell'attaccante in esecuzione sul browser della vittima non è in grado di leggere la risposta della richiesta cross-site falsificata.

Detto questo, dovresti leggere parte 2 del manuale sulla sicurezza del browser e prendere seriamente in considerazione la possibilità di raccogliere una copia di Il Web intricato .

risposta data 28.08.2012 - 02:20

fonte

2

Il comando document.myform.submit() attiva un'azione browser e un evento di navigazione. Ciò significa che non è limitato dalla stessa politica di origine . Se invece avevi provato a inviare la richiesta come XHR e interpretare il risultato usando lo stesso codice JS in esecuzione, allora potresti hai incontrato difficoltà.

risposta data 28.08.2012 - 04:48

fonte

Leggi altre domande sui tag web-browser csrf same-origin-policy

Qual è il vantaggio di JWT se l'utente deve inviare le sue credenziali una volta in ogni caso? Come intercettare un'applicazione che ignora il proxy locale

score 5 · Accepted Answer

Ahh! Penso di poterti spiegare.

foo.com può navigare nel browser verso qualsiasi pagina o dominio. Pertanto, foo.com può inviare un modulo che pubblica su localhost , anche se si tratta di un dominio diverso. Nessun problema.
Dopo aver navigato verso una nuova pagina, il browser mostrerà felicemente il contenuto della nuova pagina all'utente. Ad esempio, dopo aver inviato il modulo a localhost , il browser mostrerà felicemente la risposta da localhost all'utente.

Questa non è una violazione della politica dell'origine stessa, perché la risposta viene mostrata all'utente , non a foo.com . L'utente è affidabile e non è limitato dalla politica della stessa origine. La politica della stessa origine limita solo i siti Web, non l'utente.
In nessun momento foo.com può leggere la risposta da localhost . Il browser mostrerà la risposta da localhost sullo schermo, ma foo.com non può leggerlo. Che è ciò che impedisce la stessa politica di origine.

Quindi, in sintesi: la politica della stessa origine non impedisce a un sito di navigare nel browser verso un altro sito. Non impedisce a un sito di attivare una richiesta su un altro sito. Tuttavia, non impedisce al primo sito di leggere la risposta a tale richiesta al secondo sito.