Cross-site request forgery (CSRF)

Descrizione generale CSRF è un tipo di attacco che forza un utente ad eseguire azioni non volute su una applicazione web nella quale è autenticato.

Con un pò di aiuto grazie al social engineering (come inviando il link tramite email/chat), un attaccante potrebbe forzare l' utente di una applicazione web ad eseguire azioni scelte appositamente dall' attaccante.

Un exploit CSRF può compromettere i dati e operazioni dell' utente nel caso di utenti normali. Se l' utente finale scelto è un amministratore, è possibile compromettere l' intera applicazione.

CSRF non è lo stesso attacco XSS (Cross Site Scripting), che forza contenuto malevolo ad essere servito da un sito fidato ad una vittima insospettata.

Gli attacchi di tipo Cross-Site Request Forgery (CSRF) (C-SURF) (Confused-Deputy) sono considerati utili se l' attaccante sa che la vittima (target) è autenticato ad un sistema web.

Tali attacchi funzionano solo se la vittima è loggata nel sistema, e quindi hanno un small attack footprint. Altra debolezze logiche sono inoltre necessarie come la mancanza per esempio di una autorizzazione alla transazione (transaction authorization).

Gli attacchi CSRF funzionano inviando una malevola richiesta HTTP da un browser di un utente autenticato su una applicazione, che quindi committa una transazione senza l' autorizzazione data dall' utente. Fino a quando l' utente è autenticato e una significativa richiesta HTTP è inviata dal browser dell' utente verso l' applicativo target, l' applicazione stessa non sa se l' origine della richiesta è una transazione valida o un link cliccato dall' utente (per esempio presente in una email) mentre l' utente è autenticato.

Quindi, per esempio, utilizzando CSRF, un attaccante fa si che sia la vittima stessa ad eseguire un' azione che non conosce o di cui non ha intenzione, come il logout, comprare un oggetto, chiedere informazioni sul conto, o qualsiasi altra funzione offerta dall' applicazione vulnerabile. Di seguito un esempio di una richiesta HTTP POST ad un venditore per comprare un numero.

Contromisure:

Quindi controllare che la request abbia un valido Session ID non è sufficiente, dobbiamo controllare che un identificatore univoco sia inviato ad ogni richiesta HTTP verso l' applicativo.

ID univoco per request: identificativo è renderizzato in pagina come campo nascosto (hidden field) ed è appeso alla richiesta HTTP una volta cliccato il link/bottone.

L' attaccante non sarà a conoscenza di questo identificativo (unique ID), poiché è generato randomicamente e renderizzato dinamicamente per ogni link per ogni pagina.

\1. Una lista è compilata prima di servire la pagina all' utente. La lista contiente tutti gli IDs validi generati per tutti i link della pagina servita. L' ID univoco può essere generato da un sicuro generatore random come per esempio il SecureRandom (J2EE).
\2. Un ID univoco è appeso ad ogni link/form sulla pagina richiesta prima di essere renderizzata all' utente.
\3. Mantenere la lista degli IDs univoci nella sessione dell' utente, l' applicativo deve controllare se l' ID univo passato nella HTTP request sia valido per una data richiesta.
\4. Se l' ID univoco non è presente, terminare la sessione e mostrare la pagina di errore.