ASP.NET MVC - Attacco CSRF

C'è un tipo di attacco a cui siamo inclini e che molte volte trascuriamo, questo è il Falsificazione della richiesta su più siti o CSRF, questo è responsabile di indurre la nostra applicazione a ricevere dati che non provengono dal dominio in cui è ospitata.
Questo tipo di attacco è abbastanza dannoso poiché fa sì che un utente che è stato ingannato utilizzi la propria autenticazione per inserire dati nel nostro database, immagina che con un attacco di questo tipo un utente amministrativo o magari una notizia falsa sia riuscito ad entrare nella nostra sezione delle notizie .
Come abbiamo spiegato, questo attacco inganna la nostra applicazione per ricevere dati che non provengono da se stessa, per questo sfrutta il modo in cui i protocolli funzionano come HTTP e i suoi diversi metodi, quindi un utente malintenzionato può creare un modulo e puntare al nostro controller.
Per illustrare questo attacco, diamo un'occhiata al seguente controller che è vulnerabile a questo tipo di attacco:

Qui possiamo vedere come otteniamo i dati direttamente dal nostro modulo e questo non è male, l'unico problema è che non diciamo alla nostra applicazione che deve convalidare la sua origine, con questo un utente malintenzionato può generare uno script come il seguente:

INGRANDIRE

Qui è chiaro cosa succede, caricando questa pagina, viene inviato il form che punta ad uno specifico record nel database, questo form punta ad un controller valido, quindi se un utente autenticato viene indirizzato a questa pagina probabilmente siamo in un un po' di vincolo.
Nonostante quanto fatalistico possa essere, questo attacco è evitabile, per questo dobbiamo solo fare alcune convalide che garantiscano che i dati ricevuti provengano dalla nostra applicazione, per questo possiamo usare alcune di queste tecniche:
Riferimento al dominioQuesto consiste nel verificare da quale dominio proviene la richiesta, con questo garantiamo che proviene solo dal dominio in cui è ospitata la nostra applicazione, l'unico problema o svantaggio è che se migriamo la nostra applicazione di dominio potremmo dover ricostruire la convalida nel caso non abbiamo reso dinamico. È anche possibile fare un riferimento falso sfruttando le vulnerabilità dell'applicazione come Adobe Flash.
Token generatoCon questa opzione ciò che facciamo è che all'interno del nostro modulo a gettone che è unico per utente, quindi la nostra applicazione quando riceve i moduli convalida che il token è lo stesso, in questo modo consente l'accettazione o meno dei dati. Questa è l'opzione più utilizzata in quanto è molto facile da implementare e presenta pochi o nessun inconveniente.
Nel caso del token generato ASP.NET MVC contiene alcuni metodi che possono aiutarci, il principale è @ Html.AntiForgeryToken () che genera la chiave segreta con cui la nostra applicazione può convalidare i moduli.
Vediamo quindi che ci sono più aree di quanto pensiamo e di cui dobbiamo occuparci nelle nostre applicazioni, quindi dobbiamo informarci ed essere consapevoli di come si verificano gli attacchi per escogitare modi per evitarli.