CSRF, questa sigla compare più volte nelle note di aggiornamento del Core di WordPress. Il metodo che sta alla base di questo fenomeno è ormai vecchio e sfrutta i cookie, solitamente abbondanti, di un browser. Fortunatamente, però, puoi proteggerti dalla Cross Site Request Forgery in modo piuttosto semplice. Tutto ciò che ti serve è un po' di tempo e di attenzione.

Sicuramente utilizzi diversi servizi che offrono la possibilità di rimanere connessi anche dopo aver lasciato il sito web. Se poi visiti di nuovo il sito, non dovrai inserire nuovamente i tuoi dati di accesso, ma verrai connesso direttamente. Ovviamente questo è un aspetto positivo perché, proprio come la gestione delle password o il cosiddetto single sign-on, ti evita di dover compilare dei moduli.

Quando accedi al sito per la prima volta, il sito inserisce un cookie nel tuo browser. Si tratta di un piccolo file di testo in cui possono essere memorizzate alcune informazioni. Nel caso in cui si rimanga connessi, si tratta di una stringa generata in modo casuale.

La volta successiva che visiti il sito web, il server controlla questa stringa e, se riesce a trovare la controparte corrispondente, ti registra automaticamente. Questo è anche il motivo per cui, quando svuoti la cache del browser, vieni disconnesso ovunque. Perché durante questo processo vengono cancellati anche tutti i cookie.

Gli attacchi CSRF sono fondamentalmente un abuso di fiducia.

Come puoi vedere, in un attacco corrispondente, il servizio che legge i cookie viene ingannato. Di seguito ti spiegherò come ciò avviene esattamente con due esempi.

Il pericolo di questa manipolazione risiede nel fatto che qualcuno apporti modifiche al tuo profilo Facebook a tuo nome, ad esempio. Tuttavia, il cross site request forgery dipende spesso anche dal phishing. Anche in questo caso, la fiducia diventa importante: la fiducia nei mittenti delle e-mail, ad esempio.

Quanto è in pericolo WordPress?

Probabilmente non hai sentito il termine Cross Site Request Forgery tanto spesso quanto attacchi brute force o cross site scripting. C'è un motivo: l'organizzazione no-profit OWASP (Open Web Application Security Project) pubblica regolarmente un elenco delle dieci vulnerabilità più critiche nelle applicazioni web. Nel corso degli anni, la CSRF è scivolata sempre più in basso nell'elenco dei rischi per la sicurezza e ora è scomparsa dalla top 10.

Probabilmente questo è dovuto in parte al fatto che gli attacchi CSRF sono vecchi come Internet. Gli sviluppatori professionisti sono ormai abituati a proteggere il loro codice da questi attacchi. Quindi i rischi per la sicurezza sono abbastanza facili e veloci da risolvere.

Anche WordPress è in guardia. Ad esempio, sul sito Mai è stato pubblicato l'aggiornamento di sicurezza 4.7.5, che ha risolto sei vulnerabilità che gli hacker avrebbero potuto utilizzare per sferrare un attacco tramite cross-site scripting o cross-site request forgery. Tuttavia, il cross-site scripting è spesso considerato molto più pericoloso.

Inoltre, il problema della Cross Site Request Forgery tende a essere più rilevante per i plugin e le app che per il web design, le agenzie e le PMI. Questo perché la protezione contro il CSRF è anche una questione di programmazione. Il CSRF potrebbe diventare rilevante nel caso di acquisti all'interno del plugin, ad esempio.

Ma come funziona ora l'intera faccenda?

L'anatomia della Cross Site Request Forgery

L'idea alla base di un attacco CSRF è relativamente semplice e di solito avviene in due fasi:

• La vittima viene indotta a caricare un sito web manipolato o a cliccare su un link, ad esempio facendo credere che il messaggio provenga da una persona fidata. Oppure viene sfruttata la curiosità umana. In altre parole, il phishing svolge un ruolo importante in questo tipo di attacco.
• Quando si carica o si clicca sui link o sui siti web manipolati, il browser della vittima esegue una richiesta HTTP senza che la vittima si accorga di nulla.

Due esempi relativamente semplici illustrano il funzionamento di questo tipo di attacco.

Supponiamo che Justus voglia trasferire 100 euro a Bob tramite il sito web www.bank.de e che Skinny sia in attesa di effettuare un attacco CSRF. Skinny può utilizzare il metodo GET o POST per il suo attacco.

A proposito, i seguenti esempi provengono dalle seguenti fonti:

• "Cross Site Request Forgery (CSRF)" - l'articolo della rivista OWASP
• "Prevenire gli attacchi CSRF nell'WordPress uso di nonces" - di qnimate.com

Cross Site Request Forgery con il metodo GET

Il metodo GET viene utilizzato per richiedere una risorsa da un server, ad esempio un file HTML. I parametri necessari per la chiamata vengono semplicemente aggiunti all'URL. E come sappiamo già dalle iniezioni SQL: Un URL è relativamente facile da manipolare.

Justus si collega a www.bank.de e inserisce tutti i dati necessari. Il seguente input (completamente fittizio) verrebbe trasmesso al server:

GET http://bank.de/transfer.do?acct=BOB&betrag=100 HTTP/1.1

Skinny ora costruisce un URL che trasferisce 100.000 euro sul proprio conto. L'aspetto è il seguente:

http://bank.de/transfer.do?acct=SKINNY&betrag=100000

Naturalmente, Justus deve eseguire l'azione nascosta dietro il falso link. Pertanto, Skinny invia a Justus una mail con un link falso. Il codice HTML può essere simile a questo, ad esempio:

<a href="http://bank.de/transfer.do?acct=SKINNY&betrag=100000">Wer dieses Rätsel nicht lösen kann, ist kein echter Detektiv!</a>

Oppure gli invia un'e-mail contenente un'immagine "invisibile" (perché 0 x 0 pixel). Quando cerca di caricare l'immagine, il browser accede all'URL senza che Justus se ne accorga:

<img src="http://bank.de/transfer.do?acct=SKINNY&betrag=100000" width="0" height="0" border="0">

Quando Justus richiama il link - consapevolmente o meno - i parametri vengono passati al server, il trasferimento viene attivato e 100.000 euro scompaiono dal suo conto.

Naturalmente, Justus deve cliccare sul link mentre è connesso. Ma se, sfortunatamente, nel suo browser è presente un cookie di login della sua banca, l'attacco funziona anche se non ha il sito web aperto al momento.

È proprio questo che rende la Cross Site Request Forgery così insidiosa: Justus probabilmente non è nemmeno a conoscenza dell'esistenza del cookie.

Cross Site Request Forgery con il metodo POST

Il metodo GET può essere utilizzato nei link ed è quindi particolarmente facile da diffondere. Tuttavia, i provider possono ora garantire che le richieste GET non ricevano il permesso di scrittura in linea di principio.

Rimane il metodo POST: in questo caso, i dati vengono trasferiti a un server affinché possa elaborarli ulteriormente. I dati non fanno parte dell'URL, ma vengono aggiunti all'intestazione.

Può sembrare un po' macchinoso, ma sicuramente conosci il caso d'uso, perché i moduli funzionano in questo modo.

Per il nostro attaccante Skinny, questo significa che deve impegnarsi di più ma può comunque arrivare in porta.

Stesso scenario: Justus vuole trasferire del denaro a Bob. Compila quindi il seguente modulo all'indirizzo www.bank.de:

<form method="POST" action="geld_ueberweisen.php">

    <input type="text" name="von">

    <input type="text" name="an">

    <input type="text" name="betrag_in_euro">

    <input type="submit">

</form>

Questo invia il comando money_transfer.php, che si presenta così:

if(isset($_FORM["von"]) && isset($_FORM["an"]) &&isset($_FORM["menge_in_euro"]) && isset($_CMOKIE["user_eingeloggt"]))

{

    transMoney("von", "an", "betrag");

    echo "Überweisung erfolgreich!";

}

Come puoi vedere, il codice utilizza innanzitutto il cookie per verificare se Justus ha effettuato l'accesso. Solo allora il trasferimento verrà eseguito.

Skinny ora deposita un modulo invisibile su un sito web manipolato, ad esempio:

<form method="POST" action="http://www.bank.de/geld_ueberweisen.php">

    <input type="text" name="von" value="Justus" style="display: hidden">

    <input type="text" name="an" value="Skinny" style="display: hidden">

    <input type="text" name="betrag_in_euro" value="100000" style="display: hidden">

    <input type="submit" value="Wer dieses Rätsel nicht lösen kann, ist kein echter Detektiv!">

</form>

Invia il link a questo sito web manipolato a Justus. Quest'ultimo si sente stimolato, clicca sul pulsante per vedere il puzzle e inconsapevolmente esegue la funzione geld_ueberweisen.php. Poiché questa funzione trova un cookie corrispondente nel suo browser, 100.000 € vengono trasferiti nuovamente a Skinny.

Attacco tramite deviazioni

Ecco perché si chiama cross-site request forgery: il comando viene solitamente inviato da un altro sito web. Per attaccare il sito web A, deposita un codice maligno sul sito web B. La vittima viene quindi attirata qui in modo che il suo browser esegua il codice. Poi attira qui l'ignara vittima in modo che il suo browser esegua il codice.

Come proteggersi dagli attacchi CSRF

La buona notizia: la Cross Site Request Forgery è nota da tempo. Il rischio è noto e lo sviluppo sta lavorando specificamente per eliminarlo.

La cattiva notizia è che non è possibile proteggersi dal punto di vista tecnico. Il nucleo di WordPress è relativamente ben protetto e, come puoi vedere dai continui aggiornamenti, si lavora costantemente su di esso. Come per altri tipi di attacchi, la maggior parte delle vulnerabilità proviene dai plugin. Quindi devi fidarti del fatto che lo sviluppo delle estensioni che utilizzi stia facendo un buon lavoro.

Questo significa specificamente:

• Non installare troppi plugin e installa solo quelli di cui hai veramente bisogno.
• Fai attenzione ai plugin che non sono stati aggiornati da molto tempo. Qui potrebbero nascondersi delle falle di sicurezza non risolte.
• Informati prima sui plugin che stai installando, ad esempio sulla loro compatibilità con altri plugin o sulla versione di WordPress che stai utilizzando (in modo che il plugin possa essere aggiornato).
• Aggiorna regolarmente i tuoi plugin e il nucleo di WordPress. Perché gli aggiornamenti continui servono proprio a colmare queste lacune di sicurezza.
• Sii critico nei confronti del phishing.
• Se non sei sicuro, dai un'occhiata al plugin nel repository di WP. Quali sono le valutazioni, quali sono stati i problemi maggiori in passato e se il plugin non ha chiuso una falla di sicurezza importante?

Conclusione: il CSRF è ormai superato

Il Cross Site Request Forgery esiste fin dall'inizio dell'era digitale. Inoltre, il numero di casi è estremamente ridotto rispetto agli attacchi brute force.

Ciò è confermato anche dalla valutazione di OWASP: qui si ipotizza che l'attacco sia piuttosto diffuso, facile da rilevare e grave solo in casi molto specifici.

Tuttavia, è bene sapere come funzionano gli attacchi. Perché spesso gli attacchi funzionano solo grazie all'errore umano. Più volte gli utenti aprono le e-mail per curiosità o cliccano su link che avrebbero fatto meglio a non aprire.

Il modo migliore per proteggersi dal cross-site request forgery è fare ricerche e usare un po' di buon senso.