CSRF ad alto livello

Uno dei requisiti fondamentali di una protezione CSRF correttamente implementata è che il token anti-CSRF deve essere univoco per ciascun utente. Il server Web dell'utente malintenzionato può ottenere un token a dal sito vulnerabile, ma non (beh, non dovrebbe) essere il token della vittima. Se il sito invia lo stesso token anti-CSRF a tutti gli utenti, il sito è vulnerabile a CSRF; vai a recuperare il token anti-CSRF usando il tuo account utente e usalo per attaccare altri utenti.

Questo lato client (il sito Web dell'attaccante, anziché il server Web, recupera il token) non funzionerà a causa della politica dell'origine stessa (a meno che il sito vulnerabile disponga anche di una configurazione CORS estremamente insicura, che è un tutta la diversa vulnerabilità). L'utente malintenzionato può richiedere al browser della vittima di richiedere una pagina sul sito di destinazione, ma il sito dell'aggressore non può vedere quale sia la risposta, quindi non sarà in grado di trovare il token anti-CSRF della vittima in quel modo. Se questo ti sorprende, vai a leggere sulla politica della stessa origine; è una delle protezioni più critiche offerte da un browser web (senza di essa, non potresti mai essere registrato in modo sicuro in un sito e sfogliarne un altro).

In genere un token CSRF dovrebbe essere generato lato client nel file Javascript in modo che le schede del browser siano separate da una sandbox e utilizzino diversi token anche se si è sulla stessa macchina. Ciò significa che il server non fornisce mai token CSRF che puoi richiedere.