Cross - site request forgery

Il framework sottostante fornisce protezione per l'applicazione contro CSRF (cross - site request forgery), che sfrutta in modo dannoso un sito Web in cui vengono trasmessi comandi non autorizzati da un utente affidabile per il sito Web.

CSRF (chiamato anche XSRF) è diverso da cross - site scripting (CSS o XSS), che sfrutta l'attendibilità che un utente ha per un particolare sito. CSRF è anche noto come attacco con un solo clic, sidejacking o session riding.

CSRF funziona includendo un link o uno script in una pagina che accede a un sito a cui l'utente è noto (o si suppone) di aver autenticato. Ad esempio, l'utente A potrebbe navigare in un forum in cui l'utente B ha pubblicato un messaggio. Con CSRF, l'utente B potrebbe creare il seguente elemento immagine HTML che, invece di essere un file immagine, fa riferimento ad uno script sul sito web della banca dell'utente A e richiede un prelievo di $1.000.000:

<img src="http://bank.example/withdraw?amount=1000000&for=USER-B">

Se la banca dell'utente A conserva le proprie informazioni di autenticazione in un cookie, e se il cookie non è scaduto, il tentativo da parte del browser dell'utente A di caricare l'immagine invierà il modulo di prelievo con il cookie di autenticazione e autorizzerà una transazione senza l'approvazione dell'utente A.

In questo scenario, il problema può essere riassunto nei seguenti tre punti:

A causa della politica del browser, i cookie di autenticazione vengono inviati al server della banca anche se la richiesta è stata originata da un sito web diverso.
La banca dell'utente A memorizza le informazioni di autenticazione in un cookie e si basa completamente sui cookie per scopi di autenticazione.
La banca dell'utente A non fa differenza tra le richieste GET e POST.

La protezione CSRF nel framework sottostante non si applica al primo punto, poiché si tratta di una politica del browser. Ma si applica al secondo e terzo punto utilizzando sia un cookie che un token aggiuntivo per l'autenticazione. Gli attacchi CSRF vengono generalmente evitati controllando sempre un token univoco in ogni richiesta che raggiunge il server. Nel framework sottostante, il token viene utilizzato nel modo seguente:

Al termine del login, viene impostato un token appena creato per la sessione (per scopi di convalida). Questo token è disponibile sul lato client dell'applicazione.
Il token viene utilizzato nei seguenti modi:
- Questo token viene utilizzato per tutte le richieste AJAX e all'interno dei programmi di utilità del framework sottostanti.
- Quando viene effettuata una richiesta POST o GET al server, l'applicazione convalida automaticamente che il token CSRF è disponibile nella richiesta.