Come funziona AntiForgeryToken lavoro

Question

Sono nel tentativo di proteggere da CSRF e hanno due scenarious:

1. Facendo POST dall'interno di un altro sito e non riesce quando abilito AntiForgeryToken
2. Ho provato dalla mia "dannoso "Javascript (in esecuzione su un altro sito) per eseguire innanzitutto GET della pagina, analizzarlo ed estrarre RequestVerificationToken e quindi eseguire un POST. Anche questo fallisce, ma non è chiaro per me perché?

Qualcuno può spiegare perché?

Answer 1

Per motivi di sicurezza, non è possibile recuperare il contenuto da un altro dominio utilizzando AJAX.

Pertanto, altri siti non possono ottenere il token.

Answer 2

Questo sito ha alcune informazioni utili e dettagli:

Prevent Cross-Site Request Forgery (CSRF) using ASP.NET MVC’s AntiForgeryToken() helper

Answer 3

Ecco un buon tutorial su CSRF:

http://youtu.be/vrjgD0azkCw

Ecco il senso generale: Si è connessi al proprio sito web della banca. La tua banca mette un cookie sulla tua macchina in modo che possa autenticarti. Ogni volta che fai una richiesta (ad es. Carica una pagina da) yourbank.com, il browser invia il cookie al server web e il codice sul server web controlla il cookie per assicurarti di essere autenticato. Grande.

Tuttavia, mentre il cookie non è ancora scaduto, si controlla la posta e si apre una e-mail da un principe nigeriano che ti dice di fare clic su un link. Si fa clic su di esso (chi può resistere) e invece di che vi porterà alla pagina Prince ha descritto, il link vi porta a questo URL:

http://yourbank.com/transfer.aspx?amt=1000000&from=myAccount&to=princeAccount

Perché si sta già autenticato presso la vostra banca (attraverso il cookie), pensa che in realtà stai chiedendo di trasferire il denaro, quindi lo fa.

Questo è ovviamente un esempio un po 'forzato, ma ha il significato. Più realisticamente, il link potrebbe inviare una richiesta che modifica il tuo indirizzo email su un sito web del forum a cui appartieni o qualcosa del genere, in modo che possano accedervi.

Così ora, a rispondere alla tua domanda specifica:

Un modo per combattere questo (usato da Ruby e .NET e altri) è quello di includere un anti-contraffazione-token. Fondamentalmente, quando si richiede una pagina, il server include un campo nascosto con un valore crittografato. E quando invii il modulo, il sito web controlla il cookie per assicurarti di essere autenticato, ma guarda anche al valore crittografato che il browser invia e si assicura che sia valido. Il token crittografato sarebbe realisticamente un ID di sessione a cui è legato il tuo account. Quindi il server vede il cookie, ti identifica come utente 123, quindi controlla il token del campo del modulo crittografato, decodifica il valore e si assicura che il valore non crittografato corrisponda alla tua sessione o id utente o qualcosa del genere. Se lo fa, sa di procedere.

Il principe nigeriano che ti ha inviato il link non saprà quale sia l'ID della sessione, e anche se lo facesse, non sarebbe in grado di crittografarlo con la stessa chiave e l'algoritmo che sta utilizzando il sito web.

E ce l'hai. Contrastare i principi nigeriani un gettone anti-falsificazione alla volta.

(Nulla contro la Nigeria o nigeriani qui. Sono sicuro che sono belle persone. E 'solo i loro capi a volte si comportano un po' male.) :)