When implementing CSRF protection, one generally uses a CSRF cookie that must be included in the body of the request. This prevents CSRF attacks because the malicious website cannot read the other website's cookies.
Questo è fondamentalmente scorretto. Penso che tu abbia frainteso il vettore di attacco.
Un attacco CSRF (chiamato anche "session riding") sarà in genere simile a questo
- Hacker invia una email accuratamente predisposta a milioni di utenti e / o li inganna nell'aprire una pagina accuratamente predisposta del design dell'attaccante.
- Di quei milioni, alcuni utenti accederanno all'e-mail mentre il loro browser è già registrato in un sito web sicuro, e quindi ha il cookie di sessione
- Un chiaro GIF, link o script nell'email o nella pagina dannosa si indirizza a una posizione all'interno del sito Web protetto
- Poiché l'utente ha già effettuato l'accesso al sito, tutti i cookie associati a quel sito vengono automaticamente inviati insieme alla richiesta. Quindi l'attacco può "cavalcare" in cima alla sessione legittima dell'utente.
- In nessun momento l'utente malintenzionato scopre che cosa è IN il cookie. Lo sta prendendo in prestito, alla cieca.
Una mitigazione CSRF si basa sul fatto che l'attacco è realizzato in anticipo e non ha la possibilità di accedere al contenuto di nessuna delle pagine sicure (può solo emettere una richiesta cieca). Un token CSRF è incluso come variabile nascosta nelle pagine sicure del sito; quando la richiesta dell'attaccante colpisce il sito, sì ha il cookie, ma non avrà la variabile nascosta. Il sito può convalidare il cookie rispetto alla variabile e, se la variabile è mancante o errata, la richiesta viene respinta.
È certamente possibile implementare una mitigazione CSRF usando alcuni token nell'URL (oltre a, non al posto di, un cookie), ma questo approccio ha alcuni problemi. Per offrire sicurezza, il token deve cambiare di tanto in tanto (a volte per sessione, spesso per richiesta di pagina) e quando cambia, invalida tutti i segnalibri dell'utente. Inoltre, è dannatamente brutto perché un utente può vedere ciò che sembra essere goobledigook nella barra degli indirizzi.
NON dovresti implementare un meccanismo senza cookie che si basa solo sul token URL, poiché ciò causa altri problemi di sicurezza .