cookie come pericolo: Cross-Site Request Forgery

Tobias Schüring Ultimo aggiornamento 21.01.2020
7 Min.
Gli attacchi di Cross-Site Request Forgery (CSRF) WordPress sono tra gli attacchi più vecchi di tutti.

CSRF, questa abbreviazione appare ripetutamente negli aggiornamenti di sicurezza e manutenzione del WordPress Core. Il metodo che si cela dietro è ormai vecchio e sfrutta gli abbondanti cookie di un utente di Internet. Fortunatamente, è abbastanza facile proteggersi dalla falsificazione della richiesta di Cross-Site Request Forgery. Tutto ciò che serve è un po' di tempo e di attenzione.

Probabilmente utilizzate anche un certo numero di servizi che offrono la possibilità di rimanere collegati anche dopo aver lasciato il sito. Se poi visitate di nuovo la pagina, non dovete inserire di nuovo i vostri dati di accesso, ma siete loggati direttamente. Per l'utente, questo è ovviamente fantastico, perché - proprio come una gestione delle password o un cosiddetto Single Sign On - risparmia la fastidiosa compilazione di moduli.

Quanto segue avviene in background: quando si accede al sito per la prima volta, il sito web memorizza un Cookie nel tuo browser. Questo è un piccolo file di testo in cui si possono memorizzare alcune informazioni. Nel caso di rimanere connessi, questa è una stringa di caratteri generata casualmente.

La prossima volta che visitate il sito web, il server controlla questa stringa di caratteri e, se riesce a trovare la controparte corrispondente, vi registra automaticamente. Questo è anche il motivo per cui si è disconnessi ovunque quando si cancella la cache del browser. Perché questo processo cancella anche tutti i cookie .

Un attacco CSRF è, in sostanza, un abuso di fiducia.

Come potete vedere, in un attacco corrispondente, l'attaccante inganna il servizio che legge cookie facendogli credere qualcosa. Come succede esattamente questo, lo spiego qui sotto con due esempi.

Il pericolo di questa manipolazione sta nel fatto che una terza parte, cioè l'aggressore, apporta modifiche al vostro profilo Facebook a vostro nome, per esempio. Tuttavia, il cross-site request forgery dipende spesso anche dal phishing. Anche qui, la fiducia diventa rilevante - cioè la vostra fiducia, per esempio, nei mittenti delle e-mail.

Gli attacchi di Cross Site Request Forgery (CSRF) WordPress possono essere evitati con il buon senso.

Quanto è in pericolo WordPress?

Probabilmente non avete sentito il termine Cross-Site Request Forgery così spesso come Brute Force attacchi o cross-site scripting. C'è una ragione per questo: l'organizzazione non-profit OWASP (Open Web Application Security Project) pubblica regolarmente una lista delle dieci vulnerabilità più critiche nelle applicazioni web. Sulla lista preliminare per il 2017 CSRF occupa l'8° posto su 10. Nel 2007 e nel 2010, l'attacco è ancora al 5° posto, Nel 2013, è sceso al numero otto sceso.

Questo è probabilmente dovuto in parte al fatto che gli attacchi CSRF sono quasi vecchi come Internet stesso. Gli sviluppatori professionisti sono ora ben esercitati nel mettere in sicurezza il loro codice contro di loro. Quindi i rischi per la sicurezza sono abbastanza facili e veloci da risolvere.

WordPress è anche alla ricerca. Per esempio, l'aggiornamento di sicurezza 4.7.5 è stato rilasciato a maggio, che ha risolto sei vulnerabilità che gli hacker avrebbero potuto utilizzare per lanciare un attacco tramite cross-site scripting o cross-site request forgery. Spesso Il cross-site scripting è spesso considerato molto più pericoloso.

Inoltre, il problema della cross-site request forgery tende ad essere più rilevante per Plugin- e per gli sviluppatori di applicazioni che per i web designer, le agenzie e le PMI. Questo perché la protezione contro il CSRF è anche una questione di programmazione. CSRF potrebbe diventare rilevante, per esempio, nel caso di acquisti in-Plugin.

Ma come funziona il tutto ora?

L'anatomia del Cross-Site Request Forgery

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

  1. L'hacker inganna la vittima a caricare una pagina manipolata o a cliccare su un link, per esempio fingendosi una persona fidata o sfruttando la curiosità umana. In altre parole, il phishing gioca un ruolo importante in questo tipo di attacco.
  2. Quando i link o le pagine manipolate vengono caricate o cliccate, il browser della vittima esegue una richiesta HTTP senza che la vittima se ne accorga.

Due esempi relativamente semplici illustrano come funziona un tale attacco.

Per questo, supponiamo che Justus voglia inviare a Bob un messaggio tramite la pagina www.bank.de 100€, e Skinny è seduto in attesa di eseguire un attacco CSRF. Skinny può ora utilizzare, per esempio, il metodo GET o POST per il suo attacco.

A proposito, i seguenti esempi provengono dalle seguenti fonti:

Falsificazione di richieste cross-site con il metodo GET

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

Quindi 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 invece 100.000 euro sul suo conto. Sembra così:

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ò apparire così, per esempio:

">Chi non riesce a risolvere questo mistero non è un vero detective!

Oppure gli manda una mail che contiene un'immagine "invisibile" (perché 0 per 0 pixel). Quando si cerca di caricare l'immagine, il browser accede all'URL senza che Justus se ne accorga:

Quando Justus chiama il link - consciamente o inconsciamente - i parametri vengono passati al server, il trasferimento viene attivato e 100.000€ scompaiono dal suo conto.

Naturalmente, Justus deve cliccare sul link mentre è connesso. Ma se il suo browser purtroppo contiene un loginCookie della sua banca, l'attacco funziona l'attacco funziona anche se non ha aperto la pagina.

Questo è esattamente ciò che rende la cross-site request forgery così insidiosa: la vittima può anche non essere consapevole dell'esistenza di Cookie .

Falsificazione di richieste cross-site con il metodo POST

Il metodo GET può essere utilizzato nei link ed è quindi particolarmente facile da diffondere. Questo naturalmente gioca a favore dell'attaccante in termini di distribuzione. Ora, tuttavia, i fornitori possono garantire che le richieste GET non ricevano il permesso di scrittura in linea di principio.

Rimane il metodo POST: qui, i dati vengono trasferiti a un server in modo che possa elaborarli ulteriormente. I dati non fanno parte dell'URL, ma sono aggiunti all'intestazione.

Potrebbe sembrare un po' ingombrante, ma sicuramente conosci il caso d'uso. Perché le forme funzionano così.

Per il nostro attaccante, Skinny, questo significa che deve fare più sforzi, ma può ancora arrivare dove vuole.

Stesso scenario: Justus vuole trasferire denaro a Bob. Così riempie www.bank.de e compila il seguente modulo:

<modulo metodo="POST" azione="money_transfer.php">

    <ingresso tipo="testo" nome="da">

    <ingresso tipo="testo" nome="un">

    <ingresso tipo="testo" nome="importo_in_euro">

    <ingresso tipo="presentare">

modulo>

Questo invia il comando money_transfer.php, che assomiglia a questo:

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

{

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

    echo "Überweisung erfolgreich!";

}

Come potete vedere, il codice prima controlla se Justus è loggato usando l'indirizzo cookie . Solo se lo è, il trasferimento sarà eseguito.

Skinny ora deposita un modulo invisibile su una pagina web manipolata, ad esempio

<modulo metodo="POST" azione="http://www.bank.de/geld_ueberweisen.php">

    <ingresso tipo="testo" nome="da" valore="Justus" stile="display: nascosto">

    <ingresso tipo="testo" nome="un" valore="magro" stile="display: nascosto">

    <ingresso tipo="testo" nome="importo_in_euro" valore="100000" stile="display: nascosto">

    <ingresso tipo="presentare" valore="Chiunque non riesca a risolvere questo mistero non è un vero detective!">

modulo>

Manda il link a questo sito web manipolato a Justus. Si sente sfidato, clicca sul pulsante per vedere il puzzle, e inconsapevolmente esegue la funzione geld_ueberüberweisen.php. Poiché questo trova un corrispondente Cookie nel suo browser, 100.000€ sono trasferiti di nuovo a Skinny.

Attacco tramite deviazioni

Ecco perché il nome CroceSite Request Forgery: l'hacker di solito invia il comando da un altro sito. Per attaccare la pagina A, deposita del codice maligno sulla pagina B. Poi attira qui l'ignaro utente in modo che il suo browser esegua il codice.

Quanto sono pericolosi gli attacchi Cross Site Request Forgery (CSRF) WordPress?

Come proteggersi dagli attacchi CSRF

La buona notizia è che la cross-site request forgery esiste da secoli. Gli sviluppatori conoscono il rischio e stanno lavorando specificamente per eliminarlo.

La cattiva notizia è che non ci si può proteggere da questo sul piano tecnico. Il WordPress nucleo è ora relativamente ben protetto e, come si può vedere dagli aggiornamenti in corso, viene costantemente lavorato. Come per altri tipi di attacchi, la maggior parte delle vulnerabilità si accompagna ad plugin sessa. Quindi dovete avere fiducia che gli sviluppatori delle estensioni che usate stiano facendo un buon lavoro.

Questo significa specificamente:

  • Non installate troppi Plugins e solo il Plugins di cui avete veramente bisogno.
  • Fate attenzione a Plugins, che non è stato aggiornato dagli sviluppatori per qualche tempo. Le vulnerabilità di sicurezza non risolte possono essere nascoste qui.
  • Informatevi in anticipo sulla plugin sche si installa, per esempio sulla loro compatibilità con altri plugins o la WordPress versione che si sta utilizzando (in modo che plugin possa essere aggiornata).
  • Aggiornate regolarmente il vostro Plugins e il core di WP. Perché gli aggiornamenti continui sono proprio lì per colmare tali lacune di sicurezza.
  • Sei critico in termini di phishing
  • Se non sei sicuro, dai un'occhiata da vicino a Plugin nel repository di WP. Quali sono le valutazioni, quali sono stati i maggiori problemi in passato e il sito Plugin non ha forse chiuso un importante buco di sicurezza?

Conclusione: CSRF è vecchio stile

La falsificazione delle richieste cross-site esiste dall'inizio dell'era digitale. Inoltre, il numero di casi è estremamente ridotto rispetto ad esempio agli attacchi diBrute Force .

Questo è anche confermato dalla valutazione di OWASP che l'attacco è piuttosto basso profilo, facile da rilevare, e grave solo in alcuni casi specifici. casi.

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

Quindi, che tu sia un utente o un utente finale, il modo migliore per proteggerti dalla cross-site request forgery è con la ricerca e un po' di buon senso.

Articoli correlati

Commenti su questo articolo

Scrivi un commento

Il tuo indirizzo e-mail non sarà pubblicato. I campi obbligatori sono contrassegnati con *.