Può controllare le intestazioni HTTP protette contro CSRF? [duplicare]

Tutte le protezioni CSRF che fanno affidamento solo su un valore prevedibile in un'intestazione HTTP hanno gli stessi problemi di base:

• Se attivi CORS con Access-Control-Allow-Headers , potresti improvvisamente lasciare che l'intestazione X-Requested-With sia impostata sull'origine incrociata. Ovviamente, puoi risolvere questo problema semplicemente non impostando una cattiva politica CORS. (L'intestazione Referer è "proibito" e non può essere impostata indipendentemente dal tuo CORS la politica.)

• Ci sono stati exploit Flash (e se la cronologia è una guida, ce ne saranno altri) che consente di impostare le intestazioni nelle richieste di origine incrociata. Certo, Flash sta morendo, ma non è ancora morto.

• L'intestazione Referer potrebbe essere vuota per un sacco di motivi legittimi (ad esempio, rimosso da un proxy). Per rendere sicuro questo controllo, devi blocchi le richieste con un'intestazione vuota , ma che allo stesso tempo blocchi molte richieste legittime.

Quindi temo che tu debba ancora contare sull'impostazione di un'intestazione (o di qualche altra variabile) su un valore che un utente malintenzionato non può prevedere. In pratica, questo ti lascia un paio di opzioni, come un token classico, un doppio invio cookie o un token al portatore nell'intestazione auth.

Come sempre, la lettura di OWASP fornisce molte indicazioni.

OWASP ha raccomandazioni su questo argomento . In breve, dovresti avere controlli su due fronti:

1. Assicurarsi che l'origine dell'origine sia uguale all'origine del target. Utilizza l'intestazione "Origin" o "Referer", nell'ordine di preferenza. E se nessuno dei due è presente, respingi.
2. Utilizza il token CSRF

A proposito, potresti anche voler controllare Lo stesso cookie del sito come mezzo di protezione contro CSRF .