Il Cross-Site Request Forgery (CSRF) è uno degli attacchi classici all’integrità delle sessioni Web. Consente ad un attaccante che controlla un sito malevolo di inviare richieste autenticate a nome della vittima, abusando così dei suoi privilegi presso un servizio online.
L’implementazione di sessioni Web è una caratteristica fondamentale di molti servizi online. In una sessione Web, un utente si autentica presso un servizio fornendo una credenziale di accesso (tipicamente una password) e riceve un insieme di cookie, detti cookie di sessione, che permettono di identificarlo in maniera univoca e che vengono allegati automaticamente dal browser a tutte le richieste inviate al servizio.
Per mezzo dei cookie di sessione è quindi possibile fornire un’esperienza d’uso personalizzata a ciascun utente, consentendo per esempio la creazione e la gestione delle pagine profilo di un social network. Purtroppo, però, proteggere i cookie da occhi indiscreti non è sufficiente per garantire la sicurezza di una sessione Web.
Indice degli argomenti
Cross-Site Request Forgery: analisi di un attacco
Per capire il funzionamento e la pericolosità dell’attacco, immaginiamo un servizio di e-banking che permetta di effettuare un bonifico di 1.000 euro a Mario Rossi tramite il link: https://www.bank.comt/pay.php&dest=Mario+Rossi&amt=1000. Un CSRF (acronimo di Cross-Site Request Forgery) può avvenire nel modo seguente:
- l’utente accede a https://www.bank.com e si autentica tramite la propria password. L’utente esegue quindi le operazioni desiderate, per esempio la consultazione della lista dei movimenti del suo conto corrente, ma non termina la sessione con la banca tramite il pulsante di logout;
- l’utente accede a http://www.evil.com , che invia alla banca una richiesta di bonifico identica a quella che si invierebbe cliccando il link sovrastante. Per esempio il sito potrebbe includere lo stesso link e cliccarlo automaticamente tramite JavaScript;
- poichè la sessione con https://www.bank.com è ancora aperta, il browser allega automaticamente i cookie di sessione dell’utente, autenticando quindi a suo nome la richiesta di bonifico.
L’esempio evidenzia non solo la gravità di questo tipo di attacco, ma anche l’estrema facilità con cui esso può essere perpetrato: l’unica assunzione che abbiamo fatto sull’attaccante è che egli possa controllare un sito Web.
Storia e cause dei Cross-Site Request Forgery
I CSRF sono un problema noto sin dai primi anni duemila, ma hanno avuto forte risonanza mediatica per la prima volta solo nel 2008, quando due ricercatori della Princeton University identificarono tali attacchi su quattro siti estremamente popolari: ING Direct, YouTube, MetaFilter e The New York Times. Si noti che l’attacco contro ING Direct era molto simile all’attacco di esempio descritto poco sopra. Può essere sorprendente che siti così importanti fossero vulnerabili ad un attacco così semplice come il CSRF, eppure a ben vedere l’attacco è subdolo esattamente perché il comportamento di default dei browser non lo previene, anzi lo abilita.
In effetti è lecito chiedersi come mai i browser alleghino i cookie di sessione in richieste “cross-site” come quelle inviate da evil.com a www.bank.com e la risposta è da ricercarsi in due motivi: ragioni storiche ed usabilità. Questo comportamento è stato implementato dai browser fin dai loro albori, quando la sicurezza non era ancora così sentita e ben studiata come al giorno d’oggi, e cambiare adesso questo comportamento potrebbe avere un tremendo impatto sulla funzionalità del Web che conosciamo, rompendo scenari d’uso che impiegano richieste “cross-site” autenticate. Per esempio non sarebbe più possibile accedere al proprio profilo personale di un social network quando si arriva ad esso tramite il link incluso fra i risultati di un motore di ricerca, costringendo gli utenti ad inviare nuovamente la loro password per autenticarsi.
Come proteggersi dai CSRF
Poiché i browser non proteggono nativamente dai CSRF, i siti interessati a proteggersi da questo tipo di attacchi sono costretti ad implementare appropriati meccanismi difensivi su tutte le operazioni sensibili (quali i pagamenti) che mettono a disposizione dei loro utenti. Discutere nel dettaglio tutte le tecniche di protezione possibile è oltre gli obiettivi di questo articolo, ma è istruttivo presentare una panoramica generale delle difese più popolari:
- utilizzo di token anti-CSRF: l’idea è di associare ad ogni richiesta sensibile un valore segreto impredicibile per l’attaccante, comunemente detto token, in modo che egli non sia in grado di comporre una richiesta legittima. Tutte le richieste senza un token valido vanno scartate;
- utilizzo di header HTTP: le richieste spedite dai browser standard includono un header chiamato Referer, che contiene l’indirizzo della pagina dalla quale la richiesta è stata spedita. Un sito può utilizzare il contenuto dell’header Referer per filtrare le richieste cross-site indesiderate;
- utilizzo di OTP e CAPTCHA: one-time password (OTP) nello stile delle chiavette normalmente impiegate dalle banche e CAPTCHA permettono di rendere ciascuna richiesta univoca ed autenticata, richiedendo un’interazione esplicita con l’utente per essere autorizzata.
Queste soluzioni presentano diversi compromessi tra sicurezza e semplicità d’utilizzo, ma sono senza dubbio le più diffuse al giorno d’oggi. È importante osservare che i CSRF sono considerati così gravi e pericolosi che la maggior parte dei framework di sviluppo Web implementano nativamente meccanismi di protezione, che possono far pensare che i CSRF siano ormai un problema risolto. La stessa OWASP ha rimosso per la prima volta i CSRF dalla Top 10 dei problemi di sicurezza Web, ma una serie di recenti articoli di ricerca hanno dimostrato sperimentalmente che il problema è ancora molto grave e diffuso.
Per concludere
I CSRF costituiscono un serio problema per l’integrità delle sessioni Web, permettendo ad un attaccante di abusare i privilegi di un utente autenticato presso un servizio online. Al giorno d’oggi il problema è noto e ci sono varie difese efficaci per proteggersi contro di esso, ma la loro implementazione corretta non è banale; di conseguenza i CSRF sono ancora diffusi e pericolosi e vanno certamente tenuti in considerazione quando si sviluppa un servizio online che fa uso di sessioni basate su cookie.
