Perché il pattern token di sincronizzazione non può essere aggirato?

Se il sito dannoso invia tale richiesta direttamente, la sua richiesta non sarà nella sessione della vittima dell'attacco, quindi riceverà un token diverso da quello che avrebbe bisogno per attaccare con successo la vittima.

Se invece tenta di ingannare la vittima nel fare tale richiesta, i dati ricevuti saranno protetti dallo stesso criterio di origine e non sarà in grado di leggere il token dalla risposta.

Poiché un server remoto non ha accesso alla sessione utente e un URL hardcoded non può riscriversi per scoprire e includere un token e perché preferisci le richieste POST su richieste GET per operazioni sensibili alla sicurezza. Diamo un'occhiata a una possibile sequenza di azioni.

• richiede le pagine di bob.example.com
• Il server

  genera un token CSRF e lo restituisce in una risposta:

  <a href="/pay-money?to=bob;csrf=s3cr1t">Pay money</a>
  

• Eve ha iniettato un'immagine con l'URL dannoso https://bob.example.com/pay-money?to=eve;csrf=???? nella pagina. Quando l'utente lo richiede, il link non funzionerà perché Eve non conosce il token corretto in anticipo.

• Eve inietta invece un link al proprio server. Quando il suo server recupera la pagina di Bob, riceve un token diverso perché è una sessione completamente separata. Non può accedere alla sessione dell'utente a meno che il suo sito non utilizzi lo stesso dominio della pagina di Bob.

• Eve esegue il rendering di una pagina che incorpora la pagina di Bob in <iframe> . Prova a selezionare il token CSRF dal DOM, ma il modello di sicurezza del browser lo impedisce.

• Eve rende una pagina che fa una richiesta Ajax alla pagina di Bob. Cerca di analizzarla per trovare il token CSRF, ma il browser impedisce la richiesta a causa della politica della stessa origine.

Quindi, qualunque cosa provi Eve, fallirà. Questo è ancora più difficile perché i token CSRF sono spesso non solo per sessione, ma per richiesta. Ogni richiesta crea un nuovo token CSRF e invalida tutti i token precedenti. Questo rende efficacemente il token un nonce che può essere usato al massimo una volta. Eventuali richieste aggiuntive verranno quindi immediatamente rilevate dall'utente in quanto il loro token è scaduto. Per aggirare la politica dell'origine stessa, un utente malintenzionato dovrà inserire uno script nel sito (attacco XSS).