Un server di intestazione X-Requested-With è sufficiente per proteggere da un CSRF per un'applicazione basata su ajax?

Question

Sto lavorando su un'applicazione completamente Ajax-driven in cui tutte le richieste passano attraverso quello che in pratica equivale a un controller principale che, nelle sue ossa nude, simile a questa:

if(strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest') { 
    fetch($page); 
} 

È questo generalmente sufficiente a proteggere contro falsi di richieste cross-site?

È piuttosto scomodo avere un token di rotazione quando l'intera pagina non viene aggiornata ad ogni richiesta.

Suppongo che potrei passare e aggiornare un token univoco come variabile javascript globale con ogni richiesta, ma in qualche modo mi sento goffo e sembra comunque insicuro.

EDIT - Forse un token statico, come l'UUID dell'utente, sarebbe meglio di niente?

EDIT # 2 - Come Il Rook ha sottolineato, questa potrebbe essere una domanda di divisione. Ho letto le speculazioni in entrambi i modi e ho sentito sussurri lontani riguardo alle versioni precedenti del flash che sono sfruttabili per questo tipo di imbrogli. Dal momento che non ne so nulla, sto mettendo una taglia per chiunque possa spiegare come questo sia un rischio CSRF. Altrimenti, lo darò a Artefacto. Grazie.

Answer 1

Direi che è abbastanza. Se le richieste interdominio fossero consentite, saresti comunque condannato perché l'utente malintenzionato potrebbe utilizzare Javascript per recuperare il token CSRF e utilizzarlo nella richiesta forgiata.

Un token statico non è una grande idea. Il token dovrebbe essere generato almeno una volta per sessione.

EDIT2 Mike non ha ragione dopo tutto, mi dispiace. Non avevo letto la pagina che ho collegato correttamente. Dice:

una semplice richiesta di cross-site è uno che: [...] non imposta intestazioni personalizzate con la richiesta HTTP (ad esempio X-Modified, ecc)

Pertanto, se si imposta X-Requested-With, la richiesta deve essere pre-flown e, a meno che non si risponda alla richiesta di pre-volo OPTIONS che autorizza la richiesta cross-site, non verrà superata.

EDIT Mike ha ragione, a partire da Firefox 3.5, cross-site XMLHttpRequests sono permitted. Di conseguenza, devi anche verificare se l'intestazione Origin, quando esiste, corrisponde al tuo sito.

if (array_key_exists('HTTP_ORIGIN', $_SERVER)) { 
    if (preg_match('#^https?://myserver.com$#', $_SERVER['HTTP_ORIGIN']) 
     doStuff(); 
} 
elseif (array_key_exists('HTTP_X_REQUESTED_WITH', $_SERVER) && 
     (strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest')) 
    doStuff(); 

Answer 2

Non penso che questo offra alcun tipo di protezione. Un sito attaccante potrebbe ancora utilizzare xmlhttprequest per la sua richiesta cross-site ignorare il controllo.

Answer 3

Risposta breve: no. Qualsiasi utente malintenzionato dovrebbe utilizzare lo stesso Ajax per attaccare il tuo sito web. Dovresti generare un token casuale con una durata breve ma non eccessiva che dovresti aggiornare durante ogni richiesta Ajax.

Dovresti utilizzare una serie di token in javascript in quanto potresti avere più richieste di ajax in esecuzione nello stesso momento.

Answer 4

Quello che stai facendo è sicuro perché xmlhttprequest di solito non è vulnerabile alla falsificazione di richieste tra siti.

come questo è un problema lato client, il modo più sicuro sarebbe quello di controllare l'architettura di sicurezza di ciascun del browser :-)

^{(Questo è un riassunto, io sono l'aggiunta di questa risposta, perché questa domanda è molto confuso, vediamo cosa dicono i voti)}

Answer 5

Non credo che questo sia sicuro. Le stesse politiche di origine sono progettate per impedire ai documenti di domini diversi di accedere al contenuto restituito da un dominio diverso. Questo è il motivo per cui i problemi XSRF esistono in primo luogo. In generale, XSRF non si preoccupa della risposta. È usato per eseguire un tipo specifico di richiesta, come un'azione di cancellazione. Nella forma più semplice, questo può essere fatto con un tag img correttamente formattato. La soluzione proposta impedirebbe questa forma più semplice, ma non protegge nessuno dall'uso dell'oggetto XMLHttp per effettuare la richiesta. È necessario utilizzare le tecniche di prevenzione standard per XSRF. Mi piace generare un numero casuale in javascript e aggiungerlo al cookie e una variabile del modulo. Questo assicura che il codice possa anche scrivere cookie per quel dominio. Se desideri maggiori informazioni, vedi this entry.

Inoltre, per anticipare i commenti su XMLHttp che non funzionano nello script. Ho usato il seguente codice con Firefox 3.5 per effettuare una richiesta di google da html in esecuzione nel dominio localhost. Il contenuto non verrà restituito, ma usando firebug, puoi vedere che la richiesta è stata fatta.

<script> 
var xmlhttp = false; 

if (!xmlhttp && typeof XMLHttpRequest != 'undefined') { 
    try { 
     xmlhttp = new XMLHttpRequest(); 
    } catch (e) { 
     xmlhttp = false; 
    } 
} 
if (!xmlhttp && window.createRequest) { 
    try { 
     xmlhttp = window.createRequest(); 
    } catch (e) { 
     xmlhttp = false; 
    } 
} 

xmlhttp.open("GET", "http://www.google.com", true); 
xmlhttp.onreadystatechange = function() { 
    if (xmlhttp.readyState == 4) { 
     alert("Got Response"); 
     alert(xmlhttp.responseText) 
    } 
} 

xmlhttp.send(null) 
alert("test Complete"); 

Answer 6

Sì. È un approccio riconosciuto alla protezione CSRF.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Protecting_REST_Services:_Use_of_Custom_Request_Headers