CSRF possibile se i parametri non vengono passati attraverso la stringa di query?

0

Leggevo la pagina di OWASP su CSRF e nel loro esempio che usano una richiesta in cui i parametri sensibili sono memorizzati nella stringa di query:

http://bank.com/transfer.do?acct=MARIA&amount=100000

Sul mio sito faccio una richiesta in cui nulla è sensibile nella stringa di query:

http://mysite.com/accounts/delete

Ma se guardi la richiesta non elaborata puoi vedere le informazioni sensibili:

POST /ajax/deletion/account HTTP/1.1
Host: www.mysite.com
Connection: keep-alive
Content-Length: 15
Accept: application/json, text/javascript, */*; q=0.01
X-Requested-With: XMLHttpRequest
Content-Type: application/json; charset=UTF-8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: X-Mapping-fjhppofk=B8BFE26CD0B3A37348ECC6FFE3948274; connect.sid=s%3A4t4wfMTR6kCPRfwe5OEmYbse.Y%2FOfSmt%2Bo5JWDWglvUHIufOOFvfebr86CLiUcgdW6j8; 

{"account_id":35653}

Quello che mi chiedo è se sono al sicuro dagli attacchi CSRF poiché non includo alcun parametro nella mia stringa di query? Se non sono al sicuro da CSRF, in che modo un utente malintenzionato invia una richiesta falsificata?

    
posta Abe Miessler 21.08.2013 - 19:37
fonte

3 risposte

3

CSRF non richiede parametri di query.

Nello stesso articolo che hai linkato, nella sezione: " Misure di prevenzione che NON funziona ":

Only accepting POST requests
Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.

Fondamentalmente, dato che con CSRF non puoi fare alcuna ipotesi sul sito di origine, potrebbe essere il sito stesso dell'attaccante: potrebbe semplicemente avere un normale modulo HTML sul suo sito, che viene inviato al sito web della tua banca. Quando visualizzi il sito dell'attaccante, il modulo CSRF viene inviato alla banca ... il lancio dell'attacco.
Nessuna stringa di query necessaria.

    
risposta data 21.08.2013 - 19:49
fonte
1

Le richieste POST possono infatti essere trasformate in domini incrociati, ma dipende dal tipo di dati che stai cercando di pubblicare.

Sembra qualcosa del tipo: link

<form name="badform" method="post"
 action="http://bank.com/money_transfer">
    <input type="hidden" name="destinationAccountId" value="2" />
    <input type="hidden" name="amount" value="1000" />
</form>
<script type="text/javascript">
    document.badform.submit();
</script>

Se un utente malintenzionato crea una pagina HTML con questa al suo interno e attira una vittima (con Javascript abilitato) in quella pagina, allora quella richiesta POST verrà inviata e il trasferimento verrà eseguito se il client è attualmente connesso a bank.com e se non stanno utilizzando token CSRF.

Tuttavia, nell'esempio specifico, si tratta di dati JSON sottoposti a POST, non del POSTing dei parametri HTTP tradizionale.

Per questo, puoi utilizzare una delle seguenti tecniche: link

Come dice @Patrick, però, non sarai in grado di impersonare il tipo di contenuto. Pertanto, se il server verifica che il POST abbia un tipo di contenuto di application/json e lo consenta solo in questi casi e / o se l'intestazione X-Requested-With: XMLHttpRequest è selezionata, non sarà possibile. Ma se non vengono controllati, non è difficile da fare.

Risposta breve: in molti casi, sì, è possibile anche se non esiste una stringa di query e i token CSRF devono sempre essere utilizzati indipendentemente dal metodo HTTP del modulo o dal tipo di dati inviati.

    
risposta data 21.08.2013 - 19:50
fonte
0

CSRF sta facendo in modo che il browser della vittima invii una richiesta a un server, in modo tale che il server in qualche modo "agisca" sulla richiesta, in virtù della sua provenienza specifica dal browser della vittima. In molti siti, il browser della vittima invierà un valore del cookie precedentemente inviato dal sito e questo valore del cookie incarna il autenticazione. In breve, i siti target considerano la richiesta di venire dalla vittima (e, tecnicamente, lo fa) e di rappresentare la volontà effettiva del suddetto utente vittima (e quello è completamente sbagliato).

È questo valore del cookie che impedisce all'utente malintenzionato di eseguire personalmente la richiesta; poiché il cookie è memorizzato nel browser della vittima, la richiesta deve essere inviata dal browser della vittima, quindi da CSRF.

La richiesta contenuti dipende interamente dal modo in cui il sito target è progettato e da ciò che l'attaccante tenta di raggiungere. Nell'esempio OWASP, la richiesta è per un sito della banca e i parametri della richiesta codificano un trasferimento di denaro, ma questo è puramente illustrativo. È ipotizzabile che un sito specifico possa accettare richieste che non includono un carattere '?' e avere comunque un effetto benefico per l'attaccante, in particolare se l'obiettivo dell'attaccante è interrotto (es. Un link "elimina il mio account": no parametro, ma ancora un effetto non trascurabile).

    
risposta data 21.08.2013 - 19:47
fonte

Leggi altre domande sui tag