Stavo leggendo la domanda sull'uso del Synchronizer Token Pattern per la protezione da CSRF ed i commenti della risposta mi hanno incuriosito. Naturalmente, come dice l'ultimo commento, se il tuo sito ha una vulnerabilità XSS, allora CSRF non è la tua più grande preoccupazione. Ma cosa succede se l'altro sito come vulnerabilità XSS?
Permettimi di preparare il terreno.
- fakebank.com = la tua banca che ha una pagina di trasferimento di fondi che richiede l'utilizzo di un token univoco che si ottiene su una pagina get che deve essere inclusa in un post. Al momento sei loggato.
- insecurefun.com = un sito che stai visitando. Ha numerosi problemi, tra cui la vulnerabilità XSS.
- malicioussite.com = un sito spiacevole che non vorresti mai visitare, ma a quanto pare ha pubblicato qualche aggiunta su insecurefun.com.
Quindi caricate insecurefun.com e vi capita di ottenere un'aggiunta da malicioussite.com. L'aggiunta consente di reindirizzare a fakebank.com utilizzando i dati della sessione, facendo sì che fakebank.com invii al browser la pagina di conferma della conferma che include il token univoco. Quindi, l'aggiunta sfrutta la vulnerabilità XSS di insecurefun.com per eseguire javascript per ottenere il token e, infine, eseguire un post, causando il trasferimento di fondi da parte della tua banca.
Ora, sono abbastanza sicuro che questo non possa funzionare, perché se il Synchronizer Token Pattern potrebbe essere sfruttato così facilmente, non sarebbe raccomandato come protezione contro gli attacchi CSRF. Ma quello che non capisco è perché questo non può essere sfruttato.
La mia unica ipotesi è che lo script dannoso non possa ottenere una sospensione del token univoco per usarlo a causa dello stesso criterio di dominio. Ma se fai qualcosa come questo , sembra che lo script dannoso possa avviare il GET avere l'HTML restituito come stringa, analizzare i dati per il token univoco e quindi avviare il POST senza che l'utente sia informato. Cosa mi manca che impedirebbe che funzioni?
