CSRF: l’attacco Cross Site Request Forgery spiegato in breve

Pochissimi utenti sono davvero consapevoli dei pericoli in cui possono imbattersi navigando in Internet. Oltre allo spear phishing, uno strumento attualmente molto in voga fra i cybercriminali è il Cross Site Request Forgery. Con questo metodo, gli hacker riescono ad esempio a far partire bonifici verso conti sconosciuti tramite online banking. Ma come funziona esattamente questo metodo d’attacco? E come ci si può proteggere?

Supponiamo che un utente abbia eseguito il login a una piattaforma online. Dopo il login, l’utente rimane collegato per la durata della sessione (questo lasso di tempo viene gestito in modo molto diverso), senza dover immettere nuovamente la password. Questa situazione viene sfruttata dai criminali informatici: nella maggior parte dei casi, gli utenti collegati possono infatti eseguire più azioni e di più ampia portata rispetto agli utenti non collegati.

Il principio del CSRF spiegato in breve: mentre l’utente è collegato al portale, visita anche un altro sito web creato dall’hacker. Qui, l’utente esegue un’azione qualunque, ad esempio premere un pulsante. In seguito a questa azione, l’hacker invia una richiesta HTTP al portale utilizzato dall’utente e, camuffato con l’identità di quest’ultimo, esegue un’azione dannosa sfruttando il fatto che la sessione è ancora attiva. Per poter raggiungere il suo obiettivo, l’hacker deve soltanto conoscere la richiesta HTTP corretta che, tuttavia, è abbastanza semplice da individuare.

Il server del portale riconosce la richiesta HTTP come formulata correttamente e, leggendo i cookie corrispondenti, rileva che l’utente (o il relativo browser) è ancora collegato. Il server esegue l’azione e l’utente può non accorgersi che è appena stata effettuata un’operazione a suo nome.

L’attacco CSRF ha quindi successo perché il server ricevente non verifica la provenienza della richiesta. Il server non riesce nemmeno a sapere se la richiesta HTTP è stata generata tramite il proprio sito web o da un’origine esterna. L’autore dell’attacco sfrutta pertanto una debolezza del browser: quest’ultimo, infatti, inoltra le richieste senza valutare le conseguenze.

Le varianti di attacco CSRF utilizzate più di frequente sono tre: la più diffusa è l’invio di un URL trappola. Questo viene nascosto su un sito web esterno o in un’e-mail. L'apertura di questo URL fa partire la richiesta HTTP. In linea di principio, un URL è visibile dall’utente, a condizione che quest’ultimo vi presti attenzione. Tuttavia, alcune tecniche di social engeneering e URL spoofing permettono di camuffare l’origine dell’URL.

Esistono inoltre alcuni elementi di collegamento con il cosiddetto Cross Site Scripting (XSS): anziché costruire un proprio sito web dannoso, alcuni hacker manipolano con il XSS un sito web esistente, che viene quindi utilizzato per azioni criminali all’insaputa del gestore del sito. In generale, l’attacco consiste nell’iniettare nel sito web un codice JavaScript che, a sua volta, esegue l’attacco CSRF.

Un attacco Cross Site Request Forgery può avvenire anche quando l’hacker riesce a iniettare un software malevolo sul computer della vittima. L’hacker riesce così a comunicare direttamente al browser di inviare la richiesta HTTP. Chi, tuttavia, riesce a infiltrare virus o malware sul client, ha molte altre possibilità di attacco.

Nel nostro esempio di CSRF facciamo riferimento all’online banking poiché questo permette di capire nel modo migliore la potenziale portata di questa tecnica d’attacco. Dunque, un utente esegue il login al suo account bancario. Qui è presente un modulo specifico per eseguire bonifici. Se l’utente compila il modulo e preme il pulsante di conferma, al server viene inviata una specifica richiesta HTTP e il bonifico viene eseguito. Il cybercriminale, tuttavia, sa esattamente come sono strutturati il modulo e la richiesta HTTP ed è in grado di ricostruire entrambi. Come informazioni, vengono quindi inserite le coordinate del conto del truffatore e un importo definito da quest’ultimo.

A questo punto, l’hacker può creare un sito web (o inviare un’e-mail) che susciti l’interesse dell’utente del nostro esempio. Qui l’utente viene invitato a cliccare su un link apparentemente innocuo, cosa che tuttavia attiva la richiesta HTTP trappola. Questa viene quindi inviata alla banca, che a sua volta esegue l’azione desiderata dall’hacker. La sessione è ancora attiva e la richiesta corretta: per il server non c’è alcun motivo di non eseguire l’azione. Di conseguenza, il denaro viene trasferito. L’utente se ne accorge solo in un secondo momento, quando controlla il saldo del proprio conto.

Altri scenari di attacco:

• Social media: a nome degli utenti collegati vengono postati commenti o messi like.
• Amministrazione di siti web: se la vittima ha accesso al back end, a sua insaputa possono essere creati nuovi utenti o l’intero sito web può essere cancellato.
• Shopping online: all’insaputa dell’utente pagante, l’hacker acquista prodotti in uno shop online.

L’utente, da parte sua, è tenuto a usare cautela: chi non visita siti web dubbi o apre e-mail sospette, difficilmente cade vittima di questo tipo di attacco. Per proteggersi dal CSRF è inoltre buona norma terminare le sessioni attive su portali rilevanti per la sicurezza prima di visitare siti web della cui reputazione non si è certi.

Inoltre, l’utente deve accertarsi che il proprio dispositivo (PC, notebook, smartphone, ecc.) non contenga malware. Se è presente un’applicazione che funziona in background e spia l’utente, risulta molto più difficile impedire il CSRF. Nel caso in cui il client sia già infettato, è possibile cadere vittima di altre tecniche di attacco.

Tuttavia, anche i gestori dei siti web possono proteggere i propri utenti: gli hacker riescono a mettere a segno gli attacchi Cross Site Forgery perché conoscono esattamente la struttura dei moduli e delle richieste HTTP utilizzate dal sito. Se, invece, viene fatto entrare in gioco il fattore della casualità, l’hacker è generalmente costretto ad arrendersi. Il sito web può generare un token univoco (praticamente una sequenza di caratteri casuale) e integrarlo nella richiesta HTTP. Se il server riceve una richiesta che non contiene alcun token, o contiene un token non valido (o non più valido), la richiesta viene automaticamente rifiutata.

Nell’online banking è generalmente prevista anche un’autenticazione a due fattori: prima di poter eseguire un bonifico, gli utenti devono immettere un TAN che non viene fornito tramite il sito web. Questa tecnica protegge non solo dagli attacchi CSRF, ma anche da altri attacchi. Anche nel caso in cui l’hacker sia riuscito a spiare i dati di accesso, non potrà eseguire trasferimenti di denaro finché non indicherà il secondo fattore.

Sul piano teorico, il referer header offre già di per sé una protezione. Questa componente della richiesta HTTP indica la provenienza della richiesta. In questo modo, i siti web potrebbero applicare un filtro di esclusione a tutte le origini esterne. Ciò nonostante, in passato il referer header si è rivelato inaffidabile. Le funzionalità avanzate dei browser (come ad esempio le funzioni per il blocco delle pubblicità) modificano o cancellano il referer header. Gli utenti che hanno queste configurazioni non possono quindi più avvalersi della protezione offerta dal sito web.

Una misura che, seppur non offra una protezione assoluta, perlomeno rende più difficile la vita agli hacker, consiste nel tenere aperte le sessioni solo per un lasso di tempo limitato. A questo riguardo, gli operatori dei siti web mettono sulla bilancia il rischio e la comodità di utilizzo degli utenti. I portali delle banche, ad esempio, interrompono la sessione dopo soli pochi minuti che l’utente non fa rilevare alcuna attività. Altri siti web (come ad esempio i portali di social media), che lavorano con dati meno sensibili, lasciano tuttavia le sessioni aperte per giorni interi. Una volta che l’utente non è più connesso al portale, un attacco CSRF non ha più possibilità di successo.