AntiForgeryToken in ASP.NET MVC impedisce contro tutti gli attacchi CSRF?

Question

L'utilizzo di AntiForgeryToken richiede che ciascuna richiesta venga inoltrata a un token valido, pertanto le pagine Web dannose con semplici script che inviano i dati alla mia applicazione Web non avranno esito positivo.

Ma cosa succede se uno script dannoso in primo luogo fare qualche semplice richiesta GET (da Ajax) al fine di scaricare la pagina che contiene il token antiforgery in un campo di input nascosto, estrae, e utilizzarlo per fare una valida POST?

È possibile o mi manca qualcosa?

Answer 1

Sì, questo è tutto ciò che devi fare.

Finché si genera un nuovo token in ogni pagina protetta, con <%= Html.AntiForgeryToken() %> e sempre assicurarsi che viene controllato in ogni azione protetta, utilizzando [ValidateAntiForgeryToken]

Questo implementa il pattern Synchronizer Token come discusso nella CSRF Prevention Cheat Sheet a OWASP .

Per fare in modo che uno script riesca a fare una richiesta accettabile, dovrebbe prima ottenere il modulo e leggere il token e quindi pubblicare il token. Same Origin Policy impedirà l'accesso a un browser. Un sito canot effettua una richiesta http in stile AJAX su un altro sito; solo a se stesso. Se per qualche motivo la stessa politica di origine può essere violata, allora diventerai vulnerabile.

Si noti che se si dispone di una vulnerabilità di cross-site scripting, un utente malintenzionato può abusare della vulnerabilità xss per eludere la protezione fornita dallo stesso criterio di origine (poiché lo script è ora in esecuzione dal proprio sito, quindi SOP ha esito positivo) . Lo script iniettato può quindi leggere e inviare nuovamente il token. Questa tecnica per superare la protezione CSRF tramite XSS è stata comune in alcuni worm recentemente. Fondamentalmente, se hai XSS, la tua protezione CSRF è una perdita di tempo, quindi assicurati di non essere vulnerabile a nessuno dei due.

Un'altra cosa a cui prestare attenzione è Flash e Silverlight. Entrambe queste tecnologie non si iscrivono allo stesso criterio di origine e utilizzano invece i file di criteri di dominio incrociato per limitare l'accesso alle risorse remote. Lo script Flash/Silverlight può accedere alle risorse sul tuo sito solo se pubblichi un file xml di criteri tra domini sul tuo sito. Se pubblichi questo file, consenti sempre una whitelist di server di terze parti attendibili e non consentire mai *.

Per saperne di più CSRF at OWASP Vedi anche: XSS Prevention Cheat Sheet

Answer 2

Ma cosa succede se script dannoso farà prima un po 'semplice richiesta GET (da AJAX) in modo da scaricare la pagina contenente antiforgery token nel campo di input nascosto, estrae e usarlo per rendere POST valido?

Sì, questo è vero, ma, se non finisce in un browser questo NON è un attacco CSRF.

Se termina il browser (ad esempio lo scraping tramite una richiesta HTTP nel codice lato server), allora cosa succederebbe se il codice scrape avesse un token CSRF. Tuttavia, gli utenti legittimi e autenticati riceveranno un diverso token sul loro computer. Poiché il token che il raschietto si solleva è diverso da quello rilasciato ai tuoi utenti, il POST fallirà.

Se si desidera interrompere gli script non-browser creando post, è necessario adottare un altro approccio per convalidare che si tratti di un essere umano.