cookie come pericolo: richiesta di falsificazione di richieste di attraversamento del sito

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 una serie di servizi in cui c'è la possibilità di rimanere connessi anche dopo aver lasciato il sito. Se poi visitate di nuovo il sito, non dovrete più inserire i vostri dati di accesso, ma sarete collegati direttamente. Questo è ovviamente ottimo per l'utente, perché è - proprio come una gestione delle password o un cosiddetto Singolo Accedi - noioso modulo da compilare.

In background accade quanto segue: quando si accede al sito per la prima volta, il sito web viene memorizzato nel browserCookie. Si tratta di un piccolo file di testo in cui possono essere memorizzate alcune informazioni. Se si rimane connessi, si tratta di una stringa di caratteri generata in modo casuale.

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, tra l'altro, per cui sarete disconnessi ovunque, quando utilizzerete il vostro Cache del browser vuota. Perché questo processo li cancella tutticookie .

Un attacco CSRF è essenzialmente un abuso di fiducia

Si nota già: con un attacco corrispondente, l'aggressore finge qualcosa al servizio che li cookie legge. Come esattamente ciò avvenga viene spiegato qui di seguito con due esempi.

Il pericolo di questa manipolazione risiede nel fatto che un terzo, ossia l'aggressore, apporta modifiche al vostro profilo Facebook, ad esempio a vostro nome. Tuttavia, la falsificazione delle richieste in siti diversi dipende spesso anche dal phishing. Anche in questo caso la fiducia diventa rilevante, ovvero la vostra fiducia nel mittente, ad esempio, 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 mai sentito il termine Cross-Site Request Forgery così spesso come Brute Force Attacchi oppure scripting cross-site. C'è una ragione per questo: l'organizzazione no-profit OWASP (Open Web Application Security Project) pubblica regolarmente un elenco delle dieci vulnerabilità più critiche delle applicazioni web. Al elenco preliminare per il 2017 La CSRF occupa l'8° posto su 10. Nel 2007 e nel 2010 l'attacco è ancora atterrato al 5° posto, Nel 2013 è salito all'8° posto spento.

Uno dei motivi è probabilmente il fatto che gli attacchi CSRF sono vecchi quasi quanto Internet. Gli sviluppatori professionisti sono ora in grado di mettere in sicurezza il loro codice contro di loro. I rischi per la sicurezza sono quindi facilmente e rapidamente risolti.

Con WordPress uno è anche in guardia. Ad esempio, nel mese di maggio è stato rilasciato l'aggiornamento di sicurezza 4.7.5, che ha corretto sei vulnerabilità che avrebbero potuto essere utilizzate dagli hacker tramite il cross-site scripting o la falsificazione di richieste cross-site. Spesso ma ancora scripting cross-site è considerato molto più pericoloso.

Inoltre, la questione della falsificazione delle richieste di informazioni sul cantiere tende ad essere più per Plugin- e sviluppatori di applicazioni che per web designer, agenzie e PMI. Perché la protezione contro il CSRF è anche una questione di programmazione. Il CSRF potrebbe essere rilevante, ad esempio, per l'in-Plugin-sarà comprato.

Ma come funziona tutto questo adesso?

L'anatomia della falsificazione di richieste di attraversamento del sito

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

  1. L'hacker fa caricare alla vittima una pagina manipolata o fa clic su un link, ad esempio fingendo di essere una persona di fiducia o sfruttando la curiosità umana. In altre parole, il phishing gioca un ruolo importante in questo tipo di attacco.
  2. Quando si carica o si fa clic sui link o sulle pagine manipolate, il browser della vittima esegue una richiesta HTTP senza che la vittima se ne accorga.

Due esempi relativamente semplici illustrano il funzionamento di un tale attacco.

Diciamo solo che Justus vuole far venire Bob www.bank.de Trasferimento 100€, e Skinny è seduto in attesa di lanciare un attacco CSRF. Skinny può ora utilizzare il metodo GET o POST per il suo attacco.

A proposito, i seguenti esempi provengono dalle seguenti fonti:

Richiesta di falsificazione di richiesta in un altro sito nel metodo GET

Il metodo GET è usato per richiedere una risorsa da un server, per esempio un file HTML. I parametri necessari per la chiamata vengono semplicemente aggiunti all'URL. E come abbiamo già sentito da Iniezioni SQL sapere: Un URL è relativamente facile da manipolare.

Quindi Justus accede a www.bank.de e inserisce tutti i dati richiesti. Il seguente input (completamente fittizio) verrebbe trasmesso al server:

GET http://bank.de/transfer.do?acct=BOBetrag=100 HTTP/1.1

Skinny ora costruisce un URL che trasferisce 100.000€ sul proprio conto. Sembra proprio così:

http://bank.de/transfer.do?acct=SKINNYetrag=100000

Naturalmente Justus deve eseguire l'azione che si nasconde dietro il falso link. Per questo Skinny invia a Justus una mail con un link falso. Il codice HTML potrebbe avere questo aspetto, per esempio:

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

Oppure gli invia un'e-mail contenente 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 richiama il link - consciamente o inconsciamente - i parametri vengono passati al server, il trasferimento viene avviato e 100.000€ scompaiono dal suo conto.

Naturalmente Justus deve cliccare sul link mentre è connesso. Ma se purtroppo c'è un loginCookie della sua banca nel suo browser l'attacco funziona anche se non ha aperto la pagina in quel momento.

Questo è esattamente ciò che rende così insidiosa la falsificazione delle richieste di Cross-Site Request Forgery: la parte lesa potrebbe non essere nemmeno consapevole della sua Cookie esistenza.

Richiesta di falsificazione della richiesta in un altro sito con il metodo POST

Il metodo GET può essere utilizzato nei link ed è quindi particolarmente facile da diffondere. Questo naturalmente fa il gioco dell'attaccante in termini di distribuzione. Ma ora i fornitori possono garantire che le richieste GET non vengano autorizzate per iscritto.

Rimane il metodo POST: qui i dati vengono trasferiti ad un server in modo che possano essere ulteriormente elaborati. Tuttavia, i dati non fanno parte dell'URL, ma sono allegati all'intestazione.

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

Per il nostro attaccante, Skinny, questo significa che, anche se deve fare uno sforzo maggiore, può comunque raggiungere il suo obiettivo.

Stesso scenario: Justus vuole trasferire denaro a Bob. Così si riempie www.bank.com il seguente modulo:

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

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

    <input tipo="testo" nome="acceso">

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

    <input tipo="sottomettere">

modulo>

Questo invia il comando geld_ueberweisen.php che assomiglia a questo

se(è impostato($_FORM["da"]) && è impostato($_FORM["acceso"]) &&è impostato($_FORM["folla_in_euro"]) && è impostato($_CMOKIE["user_logged in" (utente_logged in)]))

{

    transMoney("da", "acceso", "importo");

    echo "Trasferimento riuscito!";

}

Come potete vedere, il codice controlla cookie prima di tutto se Justus è loggato. Solo se lo è, il trasferimento viene eseguito.

Skinny ora deposita una forma invisibile su un sito web manipolato, ad esempio

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

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

    <input tipo="testo" nome="acceso" valore="Magro" stile="display: nascosto">

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

    <input tipo="sottomettere" valore="Chi non riesce a risolvere questo mistero non è un vero detective!>

modulo>

Egli invia il link a questo sito web manipolato a Justus. Sentendosi sfidato, clicca il pulsante per vedere il puzzle; e poi esegue inconsapevolmente la funzione geld_ueberweisen.php. Poiché questo trova un corrispondente Cookie nel suo browser, 100.000€ vengono nuovamente trasferiti a Skinny.

attacco con mezzi subdoli

Da qui il nome Croce-Site Request Forgery: l'hacker di solito invia il comando da un altro sito. Per poter attaccare il lato A, egli deposita quindi codice maligno sul lato B. Poi attira qui l'ignaro utente in modo che il suo browser possa eseguire il codice.

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

Come proteggersi dagli attacchi CSRF

La buona notizia: la falsificazione delle richieste di attraversamento del sito è in giro da anni. Gli sviluppatori conoscono il rischio e stanno lavorando duramente 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 concretamente:

  • Non installarne troppi Plugins e solo il Pluginsdi cui avete davvero bisogno
  • Attenzione a Pluginsquelli che non sono stati aggiornati dagli sviluppatori per molto tempo. Le falle 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 Pluginse il WP-Core. Perché i continui aggiornamenti sono proprio lì per colmare tali lacune di sicurezza.
  • Siete critici nei confronti del phishing
  • Se non siete sicuri, date un'occhiata Plugin nel deposito del WP. Quali sono le valutazioni, quali sono stati i maggiori problemi in passato, e ha fatto il Plugin una violazione della sicurezza di alto profilo potrebbe non essere stata chiusa?

Conclusione: il CSRF è un vecchio cappello

Cross-Site Request Forgery esiste virtualmente dall'inizio dell'era digitale. Inoltre, il numero di casi è aumentato rispetto, ad esempio, a Brute Force Attacchi estremamente piccolo.

Questo conferma anche la valutazione di OWASPQui si presume che l'attacco sia di dimensioni piuttosto ridotte, facile da rilevare e grave solo in casi molto specifici. è.

Comunque, è bello sapere come funzionano gli attacchi. Perché spesso gli attacchi funzionano solo grazie all'errore umano. Sempre più spesso gli utenti aprono le mail per curiosità o cliccano su link che non avrebbero dovuto aprire.

Quindi, che tu sia un utente o un utente, il modo migliore per proteggerti da Cross-Site Request Forgery è fare qualche ricerca e usare un po' di buon senso.

Articoli correlati

Commenti su questo articolo

Scrivi un commento

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