Da ciò che ho letto qui , i token CSRF dall'intestazione del cookie non possono essere letto a causa della politica della stessa origine.
Sta comparando il token CSRF sull'intestazione del cookie con l'elemento nascosto del modulo?
Con questo metodo, l'implementazione del token CSRF elimina la necessità di salvare il token CSRF sul server; è un approccio corretto?
Is comparing the CSRF token on the cookie header with the form's hidden element be enough?
Un token casuale che deve essere lo stesso sul cookie e il modulo è una strategia anti-XSRF comune, il "cookie double-submit". È usato da, ad esempio, Django, quindi chiaramente è considerato abbastanza da alcuni.
È, tuttavia, più debole del pattern token sincronizzatore generalmente raccomandato (ad esempio da OWASP), in cui il token del modulo deve corrispondere a un token memorizzato sul server e associato alla sessione.
Personalmente non sceglierei questo metodo per un sito sensibile.
L'attacco a cui il cookie di doppia invio è vulnerabile, a differenza del token di sincronizzazione, è la forzatura dei cookie.
CSRF tokens from the cookie header cannot be read because of the same-origin policy.
In genere è difficile leggere un cookie proveniente da un'altra origine, in modo tale che i percorsi a tale scopo (ad esempio XSS, MitM) in genere significano che devi aver già compromesso il sito in modo abbastanza solido.
Tuttavia, la scrittura dei cookie non è bloccata, grazie al design scarso nelle specifiche dei cookie originali. Più significativamente, un sito vicino dannoso o compromesso in dodgy.example.com può scrivere un cookie con il dominio impostato per example.com che verrà letto da sensitive.example.com . Inoltre, mentre un sito protetto HTTPS è sicuro contro la lettura dei cookie da parte di un attacco man-in-the-middle a livello di rete, è possibile che un MitM generi traffico verso un dominio vicino non protetto da HTTPS che non Non c'è nemmeno bisogno di esistere e utilizzare quel dominio vicino per impostare un cookie non- secure che verrà letto dal sito HTTPS della vittima. E ci sono alcuni altri attacchi che potrebbero essere utilizzati per ottenere la forzatura dei cookie, ad esempio l'iniezione di intestazione.
Forzando un cookie sul sito della vittima, l'attaccante sa cosa deve essere il token nel modulo e così può includerlo in un modulo cross-site, evadendo il controllo XSRF. Ciò costituisce un'elevazione dell'attacco da una leggermente debole a una più strong.
Non è sufficiente per convalidare i token CSRF sul client, perché non puoi sapere se il client è l'utente o un altro sito che impersona l'utente.
Devi confrontare il token inviato dall'utente con il token che hai memorizzato sul server.
Il token CSRF deve essere controllato sul lato server.
Detto questo, il token è spesso memorizzato in un cookie, quindi il tuo approccio è ok.
CSRF funziona così:
Per richiesta:
Leggi altre domande sui tag web-application csrf