Un client invia solo moduli usando XMLHttpRequest con l'uso di un'intestazione ( X-Header: [any value would be correct] ) per proteggersi dagli attacchi di falsificazione di siti incrociati.
So che questo non è il modo giusto per prevenire le vulnerabilità di CSRF, ma come utilizzeresti questo tipo di vulnerabilità CSRF?
Il requisito è inviare una richiesta HTTP con un'intestazione personalizzata.
Questo è un metodo molto simile all'utilizzo dell'intestazione X-Requested-With , solo che invece viene utilizzato X-Header ( nessuno dei quali sono header standard, sebbene X-Requested-With possa essere considerato uno standard de facto ).
Questo è un metodo valido per prevenire CSRF poiché solo le seguenti intestazioni sono consentite per il dominio incrociato:
- Accept
- Accept-Language
- Content-Language
- Last-Event-ID
- Content-Type
tutti gli altri causano l'emissione di una richiesta di "pre-volo" nei browser supportati da CORS. I browser non CORS ignoreranno le altre intestazioni.
Se la configurazione CORS non consente l'intestazione e il dominio che l'utente malintenzionato sta utilizzando, questo è un metodo valido.
Se CORS era abilitato e stava consentendo il dominio dell'attaccante, allora altri metodi di protezione CSRF come Il modello di token di sincronizzazione fallirebbe anche perché l'utente malintenzionato potrebbe effettuare una richiesta GET per recuperare il valore del token (supponendo che l'intestazione access-control-allow-credentials sia impostata su true). Tieni presente che la mancanza di CORS non impedisce che le richieste vengano eseguite dal browser , impedisce solo la lettura delle risposte.
Quindi, sembra che sei sfortunato per un exploit CSRF, a meno che un altro bug / funzionalità di plugin per Flash o browser ti consentirà di aggiungere l'intestazione alla richiesta.
Leggi altre domande sui tag web-application csrf