Che cos'è la falsificazione di richieste tra siti (CSRF)?

Pubblicato: 2023-04-12

Le vulnerabilità di Cross-Site Request Forgery (CSRF o XSRF) sono raramente elevate o critiche nei loro livelli di gravità. Tuttavia, possono ancora fare molto male. Sono state la seconda vulnerabilità più comune di WordPress negli ultimi anni dopo le vulnerabilità di Cross-Site Scripting (XSS). Capirai come proteggere meglio il tuo sito web se sai cos'è una vulnerabilità CSRF e come gli aggressori la sfruttano comunemente.

Come aggirare la politica della stessa origine

Una vulnerabilità CSRF consente a un utente malintenzionato di eludere una funzionalità standard del browser chiamata criterio della stessa origine. Tutti i browser Web seguono questa regola per evitare il tipo di interferenza consentito dai CSRF. Normalmente quando carichi una pagina web, il tuo browser interagisce solo con un dominio o sottodominio, a parte le eccezioni consentite. E accetterà solo contenuti su un protocollo, HTTP o HTTPS (non entrambi), senza avvisarti che c'è un problema. Se individui malintenzionati ignorano la policy della stessa origine, potrebbero anche indurti a fare clic su collegamenti che eseguono azioni indesiderate interagendo inaspettatamente con un sito diverso.

Se il tuo sito WordPress è stato sfruttato attraverso una vulnerabilità CSRF, tu e i tuoi visitatori potreste essere soggetti a phishing, clickjacking e peggio. Fortunatamente, aggiornamenti tempestivi, autenticazione forte e passkey per un'esperienza di accesso senza password rafforzeranno il tuo sito WordPress e annulleranno molti exploit, inclusi i tentativi CSRF.

Visivamente, avresti pochi o nessun indizio che stai interagendo con un altro sito in modo indesiderato. Il clickjacking funziona così. Se il tuo sito WordPress è stato sfruttato attraverso una vulnerabilità CSRF, tu e i tuoi visitatori potreste essere soggetti a phishing, clickjacking e peggio.

In questa guida, analizzeremo i dettagli delle falsificazioni di richieste cross-site. Esamineremo un esempio specifico di vulnerabilità CSRF in modo da capire come funzionano. Poi ti mostreremo cosa puoi fare per prevenire l'emergere di vulnerabilità CSRF sul tuo sito. Suggeriremo anche alcuni modi per negare o limitare il danno che un exploit CSRF di successo può causare rafforzando il tuo sito contro questi e altri tipi di attacchi.

Diamo un'occhiata.

In che modo un attacco Cross-Site Request Forgery (CSRF) influisce sul tuo sito WordPress?

Quando un attacco CSRF ha successo, le sue vittime autorizzano involontariamente un'azione dannosa, come un aggiornamento delle proprie credenziali di accesso. Potrebbero essere indotti a consentire a un utente malintenzionato di assumere il controllo del proprio account utente. Peggio ancora, una vittima di un exploit CSRF potrebbe consentire agli aggressori di avviare trasferimenti finanziari per loro conto.

Se un plug-in sul tuo sito WordPress contiene una vulnerabilità CSRF, un utente malintenzionato potrebbe essere in grado di dirottare alcuni account utente. Sarebbe uno degli scenari peggiori. Se un account rubato ha un ruolo amministrativo in WordPress o l'utente riutilizza la propria password su altri siti, il danno potrebbe essere esteso.

Falsificazione di richieste cross-site

Come funziona un attacco CSRF?

Devono esistere tre diverse condizioni affinché un hacker possa far funzionare un attacco CSRF. Se li capisci a livello generale, avrai una buona conoscenza pratica di alcuni fondamenti della sicurezza web.

1. Gestione della sessione basata sui cookie

Come altre applicazioni stateless, WordPress si affida ai cookie di sessione per identificare gli utenti. In condizioni di sicurezza basse o compromesse, un utente malintenzionato potrebbe essere in grado di creare alcuni cookie di sessione falsi o manipolare un utente che ha effettuato l'accesso affinché intraprenda un'azione indesiderata. WordPress accetterà richieste contraffatte e manipolate che sono o sembrano provenire da un utente che ha effettuato l'accesso.

Sebbene gli exploit CSRF spesso prendano di mira la gestione delle sessioni basata sui cookie, questo non è il loro unico obiettivo. Gli attacchi CSRF possono essere efficaci contro qualsiasi applicazione che aggiunge automaticamente le credenziali utente alle richieste. Anche l'autenticazione basata su certificato e l'autenticazione HTTP di base sono suscettibili alle vulnerabilità CSRF per questo motivo.

2. Un'azione rilevante può essere mirata

Ci deve essere un'azione all'interno dell'applicazione mirata che le vittime possono essere indotte a intraprendere. Questa potrebbe essere un'azione privilegiata come la modifica delle autorizzazioni utente. Potrebbe essere correlato a dati specifici dell'utente, come l'aggiornamento della password di un utente. Queste sono azioni comuni in tutte le applicazioni web, incluso WordPress. Hanno valore come bersagli per gli hacker perché potrebbero aprire loro una strada per rubare gli account utente e scavare più a fondo alla ricerca di modi per impegnarsi in furti, frodi o altre attività dannose.

3. Nessun parametro di richiesta imprevedibile

Le richieste che eseguono l'azione mirata devono essere note o prevedibili. Se le richieste mirate non devono contenere parametri i cui valori l'attaccante non può determinare o indovinare, sono più vulnerabili alla manipolazione.

Ad esempio, se una richiesta di modifica della password valida deve includere la password esistente, è sicura, purché un utente malintenzionato non conosca la password. I token CSRF e i cookie SameSite aggiungono ulteriori ostacoli agli aggressori quando gli sviluppatori li utilizzano per proteggere il loro codice. Ma a volte gli sviluppatori non implementano correttamente o affatto questi metodi di sicurezza. (Questo è il motivo per cui l'autenticazione utente forte e senza password è preziosa.)

Sfruttare una vulnerabilità CSRF per modificare le e-mail dell'account utente: un esempio

Ecco un esempio più approfondito. In realtà non funzionerà, ma illustra i concetti principali in gioco per un efficace exploit CSRF.

Prendi in considerazione una richiesta di modifica dell'email. Quando un utente esegue questa azione, invia una richiesta HTTP simile a questa al server Web che la riceve:

 POST /test HTTP/1.1 Host: yourwebsite.com Content-Type: application/x-www-form-urlencoded Content-Length: 60 Cookie: session=yvthgjrudhgeQkAPzeQ5gHgTvlyxHfsAfE;[email protected]

Perché funziona

Ciò soddisfa le condizioni richieste per CSRF se/perché:

  • Il sito/applicazione di destinazione utilizza un cookie di sessione per identificare quale utente ha inviato la richiesta e non sono presenti altri token o meccanismi per tenere traccia delle sessioni utente. Questo è il motivo per cui gli sviluppatori dovrebbero utilizzare token CSRF e/o cookie SameSite.
  • La modifica dell'indirizzo e-mail di un utente è un'azione rilevante nell'interesse di un utente malintenzionato. Lo è di sicuro! Se puoi cambiare l'indirizzo email di un utente con uno che controlli, puoi assumere il controllo completo del suo account.
  • L'attaccante conosce i parametri della richiesta di cui ha bisogno per modificare l'indirizzo e-mail di un utente e può generare valori validi per loro. Questi parametri non sono segreti e non è difficile determinare quali indirizzi e-mail utilizzano molte persone per i propri account online. Il cookie di sessione è più complicato.

In che modo un utente malintenzionato potrebbe rubare i cookie di sessione

L'ostacolo principale dell'attaccante è determinare i valori effettivi per i parametri che accederanno all'account di un particolare utente. Potrebbero farlo costruendo una pagina web rivolta agli utenti del sito mirato. Questo sito ingannevole potrebbe contenere link o pulsanti che sembrano avere uno scopo legittimo, come la richiesta di omaggi. In realtà, se fai clic su quei collegamenti o pulsanti, l'unica persona che riceve gratuitamente dei dolci gadget è l'attaccante.

Quando fai clic su questi collegamenti fraudolenti, effettueranno una richiesta di modifica dell'indirizzo al sito mirato e vulnerabile CSRF. Se sei loggato in quel sito, la richiesta sarà valida. Il tuo account è stato rubato: hai consegnato le chiavi.

Gli utenti di un sito WordPress che rimangono loggati hanno un cookie di sessione attivo nel proprio browser che persiste anche quando si trovano su un sito diverso. Il loro browser includerà automaticamente quel cookie di sessione all'interno di una richiesta contraffatta. WordPress potrebbe vederlo come una richiesta di modifica dell'indirizzo perfettamente valida, anche se proviene da un altro sito e l'utente non ha idea che lo stia facendo.

Supponendo che non siano in atto altre misure di sicurezza, come l'attributo del cookie SameSite, il sito di destinazione vulnerabile elaborerà una richiesta contraffatta come se fosse valida. Se il sito Web preso di mira non impone una fase di conferma della modifica dell'indirizzo o se l'attaccante ha un modo per aggirare il problema, l'attaccante cambierà con successo l'indirizzo dell'utente con quello scelto dall'attaccante.

Come viene consegnato un attacco CSRF a un sito Web vulnerabile

I meccanismi di consegna per gli attacchi CSRF e gli attacchi Reflected Cross-Site Scripting (Reflected XSS) sono simili.

Nella maggior parte dei casi, gli aggressori inseriscono il loro codice dannoso su un sito ingannevole che controllano. Questo potrebbe essere un sito legittimo che hanno già compromesso, motivo per cui Google mantiene un elenco di siti ingannevoli. Tutti i browser avviseranno i loro utenti se sei in questo elenco! Questo è il motivo per cui iThemes Security controlla ogni giorno per assicurarsi che il tuo sito non sia diventato uno strumento di hacker.

Convincere le potenziali vittime a visitare un sito Web ingannevole è semplicemente una questione di social media di base e marketing via e-mail. A volte il codice dannoso viene semplicemente inserito in un sito popolare in un'area attiva.

Un utente malintenzionato potrebbe non aver nemmeno bisogno di un sito Web per attirare le proprie vittime. Alcuni semplici exploit CSRF utilizzano il metodo GET. Questo è ciò che fa il tuo browser quando fai clic su un collegamento o inserisci un URL nella barra degli indirizzi. Effettua una richiesta GET utilizzando l'URL nel collegamento o che fornisci. A volte un attacco CSRF può essere completamente eseguito con una singola richiesta GET a un sito Web vulnerabile. In situazioni come questa, l'attaccante potrebbe non aver bisogno di utilizzare un sito Web ingannevole. Possono semplicemente fornire direttamente alle loro vittime un URL dannoso.

Protezione del tuo sito da attacchi CSRF (Cross-Site Request Forgery).

Le vulnerabilità CSRF emergono frequentemente nei plug-in e talvolta nei temi. Quando gli hacker li prendono di mira, non è difficile proteggersi. Usa plugin e temi di qualità di cui ti fidi, rimuovi quelli che non usi e mantieni aggiornato tutto il tuo software . Dovresti anche implementare una politica di sicurezza dell'utente ben ponderata e prendere in considerazione la possibilità di passare senza password. Se una vulnerabilità CSRF (o qualsiasi altra) viene sfruttata sul tuo sito per ottenere l'accesso agli account utente, non farà molto bene all'attaccante se stai usando passkey. Nessuno può rubare ciò che non esiste.

Oltre a gestire gli aggiornamenti e avvisarti di plugin e temi vulnerabili, iThemes Security Pro semplifica l'impostazione e la gestione delle regole di sicurezza basate su utenti e ruoli. Delegare i privilegi in base al principio del privilegio minimo. Proteggi il tuo login, il recupero della password e i moduli di contatto con i CAPTCHA. Non dare ai tuoi utenti maggiori capacità di quelle di cui hanno bisogno. Richiedi agli utenti con privilegi più elevati di utilizzare metodi di autenticazione più forti. E sicuramente adotta il modo più conveniente e semplice per accedere a WordPress senza password: passkey!

Il miglior plugin di sicurezza per WordPress per proteggere e proteggere WordPress

WordPress attualmente alimenta oltre il 40% di tutti i siti Web, quindi è diventato un facile bersaglio per gli hacker con intenti dannosi. Il plug-in iThemes Security Pro elimina le congetture dalla sicurezza di WordPress per semplificare la sicurezza e la protezione del tuo sito Web WordPress. È come avere un esperto di sicurezza a tempo pieno nello staff che monitora e protegge costantemente il tuo sito WordPress per te.

Ottieni iThemes Security Pro