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

Po­chis­si­mi utenti sono davvero con­sa­pe­vo­li dei pericoli in cui possono im­bat­ter­si navigando in Internet. Oltre allo spear phishing, uno strumento at­tual­men­te molto in voga fra i cy­ber­cri­mi­na­li è il Cross Site Request Forgery. Con questo metodo, gli hacker riescono ad esempio a far partire bonifici verso conti sco­no­sciu­ti tramite online banking. Ma come funziona esat­ta­men­te questo metodo d’attacco? E come ci si può pro­teg­ge­re?

Sup­po­nia­mo che un utente abbia eseguito il login a una piat­ta­for­ma 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 nuo­va­men­te la password. Questa si­tua­zio­ne viene sfruttata dai criminali in­for­ma­ti­ci: 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 uti­liz­za­to dall’utente e, camuffato con l’identità di quest’ultimo, esegue un’azione dannosa sfrut­tan­do il fatto che la sessione è ancora attiva. Per poter rag­giun­ge­re il suo obiettivo, l’hacker deve soltanto conoscere la richiesta HTTP corretta che, tuttavia, è ab­ba­stan­za semplice da in­di­vi­dua­re.

Il server del portale riconosce la richiesta HTTP come formulata cor­ret­ta­men­te e, leggendo i cookie cor­ri­spon­den­ti, rileva che l’utente (o il relativo browser) è ancora collegato. Il server esegue l’azione e l’utente può non ac­cor­ger­si che è appena stata ef­fet­tua­ta un’ope­ra­zio­ne a suo nome.

L’attacco CSRF ha quindi successo perché il server ricevente non verifica la pro­ve­nien­za 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 con­se­guen­ze.

Le varianti di attacco CSRF uti­liz­za­te 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'a­per­tu­ra di questo URL fa partire la richiesta HTTP. In linea di principio, un URL è visibile dall’utente, a con­di­zio­ne che quest’ultimo vi presti at­ten­zio­ne. Tuttavia, alcune tecniche di social en­ge­nee­ring e URL spoofing per­met­to­no di camuffare l’origine dell’URL.

Esistono inoltre alcuni elementi di col­le­ga­men­to con il co­sid­det­to Cross Site Scripting (XSS): anziché costruire un proprio sito web dannoso, alcuni hacker ma­ni­po­la­no con il XSS un sito web esistente, che viene quindi uti­liz­za­to per azioni criminali all’insaputa del gestore del sito. In generale, l’attacco consiste nell’iniettare nel sito web un codice Ja­va­Script 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 co­mu­ni­ca­re di­ret­ta­men­te al browser di inviare la richiesta HTTP. Chi, tuttavia, riesce a in­fil­tra­re virus o malware sul client, ha molte altre pos­si­bi­li­tà di attacco.

Nel nostro esempio di CSRF facciamo ri­fe­ri­men­to all’online banking poiché questo permette di capire nel modo migliore la po­ten­zia­le 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 cy­ber­cri­mi­na­le, tuttavia, sa esat­ta­men­te come sono strut­tu­ra­ti il modulo e la richiesta HTTP ed è in grado di ri­co­strui­re entrambi. Come in­for­ma­zio­ni, vengono quindi inserite le coor­di­na­te del conto del truf­fa­to­re 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 ap­pa­ren­te­men­te innocuo, cosa che tuttavia attiva la richiesta HTTP trappola. Questa viene quindi inviata alla banca, che a sua volta esegue l’azione de­si­de­ra­ta dall’hacker. La sessione è ancora attiva e la richiesta corretta: per il server non c’è alcun motivo di non eseguire l’azione. Di con­se­guen­za, il denaro viene tra­sfe­ri­to. 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.
• Am­mi­ni­stra­zio­ne 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 can­cel­la­to.
• 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, dif­fi­cil­men­te cade vittima di questo tipo di attacco. Per pro­teg­ger­si dal CSRF è inoltre buona norma terminare le sessioni attive su portali rilevanti per la sicurezza prima di visitare siti web della cui re­pu­ta­zio­ne non si è certi.

Inoltre, l’utente deve ac­cer­tar­si che il proprio di­spo­si­ti­vo (PC, notebook, smart­pho­ne, ecc.) non contenga malware. Se è presente un’ap­pli­ca­zio­ne che funziona in back­ground 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 pro­teg­ge­re i propri utenti: gli hacker riescono a mettere a segno gli attacchi Cross Site Forgery perché conoscono esat­ta­men­te la struttura dei moduli e delle richieste HTTP uti­liz­za­te dal sito. Se, invece, viene fatto entrare in gioco il fattore della casualità, l’hacker è ge­ne­ral­men­te costretto ad ar­ren­der­si. Il sito web può generare un token univoco (pra­ti­ca­men­te una sequenza di caratteri casuale) e in­te­grar­lo 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 au­to­ma­ti­ca­men­te rifiutata.

Nell’online banking è ge­ne­ral­men­te prevista anche un’au­ten­ti­ca­zio­ne 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 tra­sfe­ri­men­ti di denaro finché non indicherà il secondo fattore.

Sul piano teorico, il referer header offre già di per sé una pro­te­zio­ne. Questa com­po­nen­te della richiesta HTTP indica la pro­ve­nien­za della richiesta. In questo modo, i siti web po­treb­be­ro applicare un filtro di esclu­sio­ne a tutte le origini esterne. Ciò no­no­stan­te, in passato il referer header si è rivelato inaf­fi­da­bi­le. Le fun­zio­na­li­tà avanzate dei browser (come ad esempio le funzioni per il blocco delle pub­bli­ci­tà) mo­di­fi­ca­no o can­cel­la­no il referer header. Gli utenti che hanno queste con­fi­gu­ra­zio­ni non possono quindi più avvalersi della pro­te­zio­ne offerta dal sito web.

Una misura che, seppur non offra una pro­te­zio­ne 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, in­ter­rom­po­no 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ù pos­si­bi­li­tà di successo.