Perché il modello di token del sincronizzatore è preferito al controllo dell'intestazione di origine per impedire CSRF

In poche parole

• L'intestazione Origin non viene inviata per le richieste di origine uguale da parte di tutti i browser .
• Bug corrente nei browser più diffusi significa che l'intestazione Origin non viene inviata per Richieste POST, che rendono questo approccio meno che inutile in quanto le richieste di modifica dello stato dovrebbero sempre utilizzare POST sopra GET.

Questo renderebbe una logica complessa quando si implementa la protezione CSRF.

Cioè:

Lack of Origin header = Old browser/bug OR
Lack of Origin header = Same Origin
Origin header matches domain = Same Origin
Origin header does not match = CSRF attack

Come puoi vedere, non è possibile distinguere tra browser vecchi o buggy che potrebbero creare attacchi CSRF e legittime richieste di browser correnti. potresti aggiungere il rilevamento del browser, ma la logica diventa più complicata. La complessità tende a ridurre la sicurezza.

Questo, naturalmente, potrebbe essere corretto in un aggiornamento del browser. Tuttavia, la tua applicazione sarebbe incompatibile con le versioni precedenti del browser.

Molto più semplice sarebbe generare un token e inviarlo con ogni richiesta al di fuori del meccanismo dei cookie.

È principalmente dovuto alla storia. Le persone erano a conoscenza della CSRF fin dai primi anni 2000, prima che l'intestazione Origin fosse stata inventata. Il concetto di "token in un campo nascosto" ha fornito ai siti un modo immediato per correggere il problema, senza attendere l'aggiornamento dei browser. Sebbene il meccanismo sia un po 'disordinato, è possibile che i framework forniscano automaticamente questa funzionalità, con pochi input dagli sviluppatori di applicazioni. In particolare, .Net ha incluso questo fin dall'inizio con EVENTVALIDATION / VIEWSTATE ed è relativamente raro che le applicazioni .NET abbiano difetti CSRF.

Quando CSRF è stato preso sul serio, alcune persone hanno proposto di controllare l'intestazione del Referer per correggere il difetto. È noto che l'intestazione di Referer è facile da falsificare, ma questa idea non è così sciocca come sembra. Quando un utente malintenzionato effettua una connessione diretta a un server Web, è facile falsificare l'intestazione di Referer. Tuttavia, in un attacco CSRF, l'attaccante non sta effettuando una connessione diretta; il browser web della vittima sta effettuando la connessione e l'utente malintenzionato non può facilmente controllare l'intestazione Referer. Tuttavia, questo approccio risulta essere ancora imperfetto. Le versioni precedenti di Flash consentivano a un utente malintenzionato il controllo gratuito dell'intestazione Referer in uno scenario di attacco CSRF. Inoltre, alcuni utenti disabilitano l'intestazione Referer per motivi di privacy, che un sito Web avrebbe errato per un attacco CSRF.

L'intestazione Origin è stata sviluppata come sostituzione più sicura per l'intestazione Referer. In molti modi, è una soluzione molto più ordinata per CSRF ed evita il sovraccarico di gestione dei token. Alcune applicazioni, in particolare le applicazioni a pagina singola, utilizzano l'intestazione Origin come unica protezione CSRF e sono completamente protette. Tuttavia, questa è l'eccezione piuttosto che la regola. Il modello sincronizzatore è ben compreso, ampiamente supportato dai framework e non ha punti deboli noti.

Modifica : Silverlightfox mi informa che quanto segue non è vero. Vedi la sua risposta per maggiori informazioni.

In definitiva penso che OWASP stia arretrando leggermente nei loro consigli. Nel 2015 dovrebbero consigliare i controlli di intestazione Origin come controllo principale, con il modello di sincronizzazione come alternativa legacy.

Qualsiasi difetto del browser, ad esempio, se consente all'intestazione Origin impostata sul lato client (altamente improbabile con i browser moderni) ora abiliterà gli attacchi CSRF contro la tua applicazione.

Inoltre, dal link

You can't currently depend on the Origin header, because it is not implemented in all browsers which are in active use. Apart from that, Origin is not sent in all cases relevant to CSRF.

Inoltre, dalla risposta di SilverlightFox a una domanda simile a link ,

There have been previous browser vulnerabilities such as those in IE 5.5/6.0 where it has been possible for attackers to bypass the Same Origin Policy and execute attacks. You can typically expect these to be patched as soon as discovered and with most browsers automatically updating, this risk will be mostly mitigated.

e

Old versions of Flash allowed arbitrary headers to be set which would enable an attacker to send a request with a spoofed referer header from the victim's machine in order to execute an attack.