Riguardavo la protezione di Spring Security della protezione CSRF per vedere come funziona. Spring non usa il modello double-submit, ma associa il token CSRF alla sessione dell'utente. La documentazione include le seguenti spiegazioni sul perché cioè:
One might ask why the expected CsrfToken isn’t stored in a cookie. This is because there are known exploits in which headers (i.e. specify the cookies) can be set by another domain. [...] See this webappsec.org thread for details on how to perform the exploit.
Il succo di ciò che dice il thread webappsec.org:
- L'attaccante inserisce il documento Flash sul sito web controllato dagli aggressori, l'utente lo visita
- L'app Flash effettua una richiesta di origine uguale al sito web degli utenti malintenzionati che imposta l'intestazione di destinazione e ciò è consentito dal file crossdomain.xml sul sito web dell'attaccante
- Il sito web degli utenti malintenzionati risponde a questa richiesta con un reindirizzamento 302 o 307 al sito web di destinazione
- Flash (in "determinate circostanze") ignora il crossdomain.xml del sito web di destinazione e inoltra la richiesta al sito web di destinazione con l'intestazione aggiuntiva inclusa
La mia domanda è: è un problema valido?
Non ero in grado di riprodurre il problema seguendo i passaggi nel thread webappsec.org, e inoltre sembra che questo fosse un bug diretto in Flash stesso piuttosto che una vulnerabilità con il pattern dei cookie double-submit. Sebbene questo problema abbia comportato almeno due CVE contro i framework delle applicazioni web Non sono riuscito a trovare alcun bug corrispondente archiviato per Flash - ma sembra o è stato corretto da allora, o non stavo riproducendo correttamente le "circostanze particolari" non specificate in cui ciò accade.