La tecnica "Double Submit Cookie" di CSRF ha un valore seme diverso per il cookie rispetto al POST HTTP?

1

Sto leggendo sul OWASP double submit cookies metodo di protezione e lì afferma che il valore del cookie tra l'intestazione e il modulo deve corrispondere.

Questo sembra essere un po 'un rischio, come afferma l'articolo, dato che il valore incorporato nel modulo è accessibile dal DOM & Javascript.

Non sarebbe più sicuro avere un valore con seme diverso per il cookie e il valore incorporato POST HTTP, in modo che uno script dannoso non possa inferire il valore del cookie

AntiForgeryToken di ASP.NET è un esempio di un doppio cookie di invio. Non mi è chiaro se quel token utilizza lo stesso valore del cookie come forma.

    
posta random65537 09.02.2011 - 16:57
fonte

2 risposte

3

Alcuni punti di nota:

  • Non utilizzare i cookie di doppia invio, come hai detto e, come afferma l'articolo, questo non è molto sicuro e ti apre agli altri attacchi.
  • "a differently seeded value for the cookie and the HTTP POST embedded value" - Sì, questo approccio è molto preferito, ma questo è non un cookie a doppio invio - ti riferisci a ciò che è noto come Token di moduli.
  • L'uso dei token modulo era più problematico, poiché era difficile riuscire a farlo correttamente ed evitare gli errori sottili che invalidano la soluzione. Al giorno d'oggi, ci sono ottimi pacchetti che fanno questo per te, come CSRFGuard di OWASP . Meccanismi simili sono anche incorporati in molti framework, tra cui ASP.NET.
  • Come ho già detto, AntiForgeryToken di ASP.NET (in realtà, questo è ASP.NET MVC ...) si basa su token di moduli e non cookie di doppia invio. Che, come detto, non è sicuro.
  • ASP.NET stesso include anche la protezione basata su ViewState, quando si utilizza l'attributo UserKey.
  • Molti altri framework moderni hanno anche alcune protezioni integrate, tra cui Spring, RoR, ecc.
  • Un'altra alternativa, che potrebbe o non potrebbe essere rilevante, è la re-autenticazione dell'utente, per azioni specifiche. Per esempio. prima di trasferire una grossa somma di denaro a una terza parte dal proprio conto bancario o autorizzando le connessioni su LinkedIn.
  • Non utilizzare i cookie di doppia invio.
risposta data 09.02.2011 - 17:59
fonte
1

Penso che tu abbia ragione che fornirebbe una protezione più strong se il cookie e la forma avessero valori diversi. Lo svantaggio è che invece di controllare solo se il valore del cookie corrisponde al valore del modulo, ora devi tenere traccia di quale valore del cookie corrisponde a ogni valore del modulo. Inoltre, come afferma la documentazione OWASP, tutto ciò si basa sul browser che applica in modo appropriato la politica della stessa origine ( che può essere più complicato di quanto suoni ) così come una generazione di valori pseudo-casuali (imprevedibile) corretta.

    
risposta data 09.02.2011 - 17:44
fonte

Leggi altre domande sui tag