Perché Double Submit Cookies richiede un cookie separato?

10

In base al link :

When a user authenticates to a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine separate from the session id.

(sottolineatura mia)

Perché il token CSRF deve essere memorizzato in un cookie separato se l'ID di sessione è:

  • un valore casuale (un valore che l'attaccante non può indovinare)
  • memorizzato in un cookie (un valore che l'autore dell'attacco non può leggere)
  • generato dal server (un valore che l'autore dell'attacco non può scrivere)

Perché non utilizzare semplicemente l'ID di sessione come token CSRF? Dovresti comunque inviare il valore due volte (una volta nel cookie, una volta nel modulo) e confrontare i valori, ma non lo farei utilizzare un cookie separato per il token CSRF.

    
posta Gili 16.06.2014 - 05:36
fonte

2 risposte

13

Il motivo è che questo consente al cookie della sessione principale di essere contrassegnato come HttpOnly (quindi non sarà accessibile a Javascript). C'è un dibattito su quanto valore aggiunge, ma HttpOnly sembra rendere più difficili alcuni tipi di attacchi è probabilmente una misura di indurimento utile.

Se non hai usato un cookie separato, ma hai semplicemente riutilizzato l'ID di sessione per questi scopi, allora Javascript avrebbe bisogno della possibilità di leggere il cookie di sessione e non saremmo in grado di contrassegnare il cookie di sessione% codice%. Utilizzando un valore separato, diventa possibile contrassegnare il cookie di sessione HttpOnly .

Ecco perché raccomandano l'uso di un valore separato.

    
risposta data 27.06.2014 - 18:14
fonte
2

Ci sono un paio di motivi per cui posso pensare:

  • Se il token CSRF è trapelato, non perde il cookie di autenticazione.
  • Ti consente di impostare il token di autenticazione come solo HTTP e di avere ancora un valore CSRF che può essere letto da JavaScript per creare richieste AJAX

Personalmente, non credo che la tecnica dei cookie double-submit sia molto efficace. Anche se non è un CSRF generale, se posso MITM il traffico di testo normale dell'utente, posso quindi eseguire CSRF su siti https-only. Ciò avviene iniettando un iframe o img con l'origine del sito sotto attacco, quindi rispondendo all'iframe o img con un proprio CSRF cookie e infine generando la richiesta cross-site. (Sì, richiede un MITM dell'utente, ma consente di eseguire un attacco MITM in chiaro su un sito servito solo su SSL senza HSTS. L'uso di HSTS attenua questo attacco, come indicato da Gili.)

    
risposta data 16.06.2014 - 05:52
fonte

Leggi altre domande sui tag