Perché i token CSRF vengono utilizzati così spesso?

Naviga le tue risposte
5

I token CSRF vengono utilizzati molto .

Il server imposta un token nel cookie per quel dominio che (1) include nel modulo HTML o (2) Javascript può leggere e includere nella richiesta. Il server verifica che il token nella richiesta corrisponda al token nel cookie.

Ma perché non controllare semplicemente l'intestazione Origin? Secondo OWASP , è per questo che esiste:

The Origin HTTP Header standard was introduced as a method of defending against CSRF and other Cross-Domain attacks.

"L'origine non è lì? Se no, OK. Se lo è, è uno di cui mi fido (ad esempio la stessa origine)? Se è così, OK."

I token CSRF possono essere fastidiosi. Sono

  • più difficile da comprendere per i principianti - "Aspetta ... lo invio due volte? Cos'è di nuovo il CRSF?"
  • richiede i cookie (concessi, di solito non è un problema)
  • più difficile da implementare - richiede la e visualizzazione
    • del controller
  • meno flessibile - non può mai funzionare in più domini
  • strano nelle impostazioni non web - "Perché la tua API ha bisogno di un token CSRF?" "Oh, perché anche JS lo usa."
  • più ingombrante da implementare globalmente - "Oops, ho dimenticato il tag CSRF qui tra i miei 25 campi del modulo HTML"

Dati questi svantaggi, perché i token CSRF sono così comunemente utilizzati, piuttosto che l'intestazione Origin?

    
posta Paul Draper 08.12.2014 - 09:51
fonte

2 risposte

6

Al momento non puoi dipendere dall'intestazione Origin, perché non è implementato in tutti i browser che sono in uso. Oltre a ciò, Origin non viene inviato in tutti i casi rilevanti per CSRF, come 

<img src=http://router/admin.cgi?...>
    
risposta data 08.12.2014 - 12:14
fonte
0

"Is the Origin not there? If not, OK. If it is, is it one one I trust (e.g. the same origin)? If so, OK."

Sebbene sia possibile utilizzare l'intestazione Origin per rifiutare una richiesta. Se manca l'intestazione Origin, non è possibile accettarlo in sicurezza, anche per le richieste POST. Per quanto ne so, una richiesta di modulo HTML non include un'intestazione di origine e nemmeno imgs, script, collegamenti, immagini di sfondo di cos o altri luoghi che fanno richieste di ottenere. E naturalmente l'intestazione Origin non viene inviata per le richieste XHR sullo stesso host, quindi è necessario un altro meccanismo di protezione.

Un'opzione consiste nel mettere il token csrf in un'intestazione personalizzata, che è più facile da fare globalmente e non inserisce il token nell'URL per ottenere richieste. E poi, se lo desideri, puoi verificare che la richiesta abbia l'intestazione Origin o l'intestazione personalizzata.

Potresti anche essere in grado di fare qualcosa come il metodo che hai menzionato, a patto di respingere qualsiasi richiesta che non sia una richiesta Ajax. Ma non sono così sicuro della sicurezza di ciò.

In breve, l'intestazione Origin, di per sé, non è sufficiente se si desidera effettuare richieste di origine identica, ma potrebbe essere utilizzata in combinazione con un altro metodo di protezione csrf.

    
risposta data 29.07.2015 - 09:35
fonte

Leggi altre domande sui tag

Secure Hash di un payload molto breve - è possibile? Il DTLS supporta SNI?