Protezione contro CSRF quando un modulo viene inviato tramite una chiamata AJAX

Question

Protezione contro CSRF quando un modulo viene inviato tramite una chiamata AJAX

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)
#4 da (-1 voti)

6

Uso i token anti-CSRF su tutti i miei moduli per prevenire gli attacchi CSRF. Inoltre, i token vengono salvati nella variabile $ _COOKIE per convalidare il valore ottenuto dal modulo. Sto reimpostando il token ogni volta che viene caricato un modulo.

Ma ci sono alcuni moduli che usano $ .post, cioè AJAX da inviare e ottenere una risposta JSON.

La variabile $ _COOKIE non è impostata a causa dell'uso di AJAX.

C'è una soluzione alternativa o sto facendo qualcosa di sbagliato?

EDIT: aggiunta di esempi di codice lato client e lato server

sul lato client:

<?php
$tokenVal = md5(uniqid(mt_rand(), true));
setcookie ("token", $tokenVal);
?>
<form action="target.php" method="post" name="abc">
<input type="text" name="city" id="city" value="abc" size="25" maxlength="10">
<input type="hidden" name="csrf" value="<?php echo $tokenVal; ?>">
<a class="cssButton buttonColor right" id="billToSubmit">Save</a>
</form>

lato server:

if($_POST['csrf'] == $_COOKIE['token']) {
//process further
} else {
die("Invalid form source")
}

Il modulo è stato inviato usando $ .post. Il problema che sto affrontando è che $ _POST ['csrf'] non è mai uguale a $ _COOKIE ['token']!

php ajax web-application appsec csrf

posta Gaurav Sharma 10.09.2012 - 22:59

fonte

4 risposte

Leggi altre domande sui tag php ajax web-application appsec csrf

iOS: Sandbox su dispositivo jailbroken Cosa viene aggiornato con "Aggiorna certificati di root" abilitato? Qual è l'equivalente in Windows 2008R2?

score 2 · Answer 1

Supponendo che il token CSRF sia disponibile per JavaScript, puoi utilizzare setRequestHeader per allegare manualmente il token di richiesta e modificare il server per cercare il token di richiesta nell'intestazione del cookie o per le richieste che dovrebbero essere accessibili tramite XHR nell'intestazione fornita.

score 1 · Answer 2

La maggior parte dei framework Javascript aggiunge un'intestazione specifica quando POST ing richieste, come X-Requested-With: AJAX . In teoria, sul backend è possibile verificare l'esistenza di questa intestazione per essere sicuri che il modulo sia stato inviato tramite AJAX (un utente malintenzionato non dovrebbe essere in grado di rendere una terza parte aggiungere un'intestazione personalizzata all'invio di un modulo). Poiché le richieste AJAX possono provenire solo dallo stesso dominio, dovresti essere al sicuro dagli attacchi CSRF.

Ma è stato scoperto che in presenza di alcune combinazioni di plug-in del browser è in realtà possibile che l'attaccante realizzi una richiesta con intestazioni personalizzate. Questo rende l'approccio di cui sopra non così bene. Oggi la protezione preferita è quella di passare il token CSRF al client anche per gli invii AJAX. Ad esempio puoi ancora aggiungerlo in un campo nascosto e poi leggerlo con javascript.

EDIT : per quanto riguarda la variabile $_COOKIE$ non impostata nelle richieste AJAX, non capisco il tuo punto. Puoi effettivamente impostare i cookie nelle richieste AJAX e anche i normali cookie verranno conservati, a condizione che non siano solo http.

score 0 · Answer 3

Questa è una forma valida di protezione CSRF perché l'utente malintenzionato non conoscerà il valore del cookie lì perché l'autore dell'attacco non avrà un valore valido per la variabile del messaggio token. Questo metodo non richiede uno stato per utente che è un vantaggio.

Il foglio Cheat di prevenzione CSRF è una buona risorsa.

score -1 · Answer 4

~~Se si utilizzano i cookie per memorizzare (e recuperare) il token CSRF, che non attenua realmente la vulnerabilità di CSRF .~~ Correzione: come chiarito nei commenti, questa linea non è vera per il modo in cui Gaurav sta usando i token CSRF.

Invece di creare il tuo schema di prevenzione CSRF, perché non utilizzare qualcosa come PHP CSRF Guard