Loading...

Guide

Proteggere il sito aziendale da Cross-Site Request Forgery

Strategie avanzate e tecniche di difesa per contrastare gli attacchi CSRF sul tuo sito web aziendale

HTTP richiesta

Indice dei contenuti

  • Che cos’è il cross-site request forgery?
  • Come funziona un attacco CSRF
  • Prevenire il cross-site request forgery
  • Esempi di attacco CSRF
  • Testing per vulnerabilità CSRF

Il cross-site request forgery, noto anche come attacco CSRF, è una delle minacce più insidiose per le applicazioni web moderne.Questo tipo di attacco consente a un malintenzionato di inviare una richiesta HTTP fraudolenta sfruttando le sessioni di un utente autenticato.

In questo articolo, verranno esplorate le strategie per prevenire gli attacchi CSRF, includendo esempi pratici, tecniche di mitigazione e metodi di testing per assicurare la sicurezza delle applicazioni web aziendali.

Che cos’è il cross-site request forgery?

Il cross-site request forgery, abbreviato come CSRF, è un tipo di attacco che sfrutta la fiducia che un’applicazione web ha per il suo utente autenticato. Questo attacco induce l’utente a inviare richieste HTTP (http request) indesiderate senza il suo consenso.

Esempio:
Un attaccante può creare un form nascosto su un sito malevolo che, quando viene caricato da un utente autenticato su un altro sito, invia una richiesta per trasferire denaro senza che l’utente ne sia a conoscenza.

Come funziona un attacco CSRF

Un attacco CSRF si basa su alcuni presupposti fondamentali:

  • L’utente è autenticato su un’applicazione web e ha una sessione attiva

  • L’attaccante induce l’utente a inviare una richiesta HTTP fraudolenta

  • La richiesta viene accettata dall’applicazione come legittima poiché proviene da un utente autenticato

Esempio di cross-site request forgery

Esempio:
Immagina un sito bancario in cui un utente autenticato può trasferire denaro inviando una richiesta POST a /transfer.

Un attaccante può creare una pagina con un form nascosto che esegue una richiesta simile:

<form action="https://bank.com/transfer" method="POST" style="width: 0; height: 0;">
    <input type="hidden" name="amount" value="1000">
    <input type="hidden" name="to_account" value="attacker_account">
    <input type="submit">
</form>

Quando un utente autenticato visita la pagina dell’attaccante, il form viene inviato automaticamente, trasferendo denaro senza il consenso dell’utente.

Prevenire il cross-site request forgery

Esistono varie tecniche per prevenire il cross-site request forgery, alcune delle quali includono:

  • Token CSRF
    Uno dei metodi più efficaci è l’uso di token CSRF. Ogni volta che una richiesta che modifica lo stato viene inviata, un token unico viene generato e inviato insieme alla richiesta. Il server verifica questo token prima di accettare la richiesta. Ad esempio, ogni form potrebbe includere un campo nascosto con il token CSRF:
<form action="/transfer" method="POST">
    <input type="hidden" name="csrf_token" value="random_token_value">
    <!-- altri campi del form -->
    <input type="submit">
</form>
  • Intestazioni HTTP personalizzate
    L’uso di intestazioni HTTP personalizzate può aiutare a prevenire gli attacchi CSRF. Le richieste legittime includono un’intestazione HTTP che le richieste di un sito esterno non possono aggiungere facilmente.
  • Verifica del Referer
    Un’altra tecnica è la verifica del Referer. L’applicazione verifica che il Referer della richiesta corrisponda al dominio della stessa applicazione. Tuttavia, questo metodo può avere limitazioni dovute a problemi di privacy e configurazioni dei browser.

Esempi di attacco CSRF

Ecco degli esempi di cross-site request forgery

  • Scenario di un attacco su una piattaforma di social media
    Un utente autenticato su una piattaforma di social media può essere indotto a cliccare su un link malevolo che esegue azioni sul suo account, come l’invio di messaggi o la modifica delle impostazioni del profilo.
  • Scenario di trasferimento di denaro (money transfer)
    Come descritto in precedenza, un utente autenticato su un sito bancario può essere ingannato nel trasferire denaro a un conto dell’attaccante semplicemente visitando una pagina web compromessa.
Proteggere dagli attacchi CSRF

Testing per vulnerabilità CSRF

L’obiettivo del testing è identificare eventuali punti deboli nel sistema che potrebbero essere sfruttati dagli attaccanti per eseguire azioni non autorizzate tramite utenti autenticati. Di seguito, analizziamo in dettaglio le tecniche e gli strumenti per eseguire un testing efficace delle vulnerabilità CSRF.

Strumenti di testing CSRF
Esistono diversi strumenti progettati specificamente per identificare e testare le vulnerabilità CSRF. Alcuni dei più utilizzati includono:

  • OWASP ZAP (Zed Attack Proxy)
    Uno degli strumenti di sicurezza web open-source più popolari, ZAP è dotato di numerosi plugin e funzioni per testare le vulnerabilità CSRF. Può essere configurato per intercettare e modificare le richieste HTTP, simulando potenziali attacchi CSRF.

  • Burp Suite
    Questo potente strumento di sicurezza web offre un’interfaccia completa per testare le vulnerabilità delle applicazioni web, inclusi i test CSRF. Burp Suite permette di automatizzare molte delle operazioni di testing, identificando i punti deboli e suggerendo possibili mitigazioni.

  • CSRF-Tester
    Uno strumento specializzato per il testing delle vulnerabilità CSRF, progettato per facilitare la scoperta di punti deboli nelle applicazioni web. CSRF-Tester consente di generare richieste HTTP personalizzate per verificare se le protezioni CSRF sono implementate correttamente.

Tecniche di attacco cross-site request forgery testing

  • Verifica della presenza di token CSRF
    Il primo passo nel testing CSRF è verificare se le richieste che modificano lo stato includono un token CSRF. Questo può essere fatto osservando il traffico HTTP durante l’uso dell’applicazione. Le richieste POST, PUT, DELETE e altre che modificano dati devono includere un token CSRF univoco. Se un token è presente, deve essere validato per assicurarsi che cambi con ogni sessione e non possa essere facilmente indovinato.
  • Manipolazione delle richieste HTTP
    Utilizzando strumenti come OWASP ZAP o Burp Suite, è possibile intercettare e manipolare le richieste HTTP per rimuovere o modificare i token CSRF. Se l’applicazione accetta la richiesta modificata senza un token valido o senza il token CSRF, significa che è vulnerabile a un attacco CSRF. È importante testare diverse varianti della richiesta per coprire tutte le possibili vie di attacco.
  • Test di verifica del Referer
    Alcune applicazioni utilizzano il campo Referer dell’header HTTP per proteggersi dagli attacchi CSRF. Durante il testing, è importante verificare se la richiesta viene rifiutata quando il Referer non corrisponde al dominio dell’applicazione. Tuttavia, questa tecnica ha limitazioni, in quanto gli utenti possono disabilitare l’invio del Referer per motivi di privacy, e alcuni proxy o firewall potrebbero rimuovere o alterare l’header.
  • Utilizzo di intestazioni HTTP personalizzate
    Le applicazioni più avanzate possono richiedere intestazioni HTTP personalizzate nelle richieste di modifica dello stato. Durante il testing, verificare se l’applicazione controlla effettivamente queste intestazioni e se rifiuta le richieste che non le includono. Questo metodo può essere testato inviando richieste senza le intestazioni richieste e osservando la risposta dell’applicazione.
  • Creazione di prove di concetto (PoC) CSRF
    Per dimostrare l’effettiva vulnerabilità, creare prove di concetto che simulano un attacco CSRF. Ad esempio, costruire una pagina HTML che invia una richiesta POST fraudolenta a nome dell’utente autenticato. Eseguire il PoC con un utente autenticato nell’applicazione target per vedere se l’attacco ha successo. Questa tecnica aiuta a dimostrare l’impatto reale della vulnerabilità.

Esempio pratico di testing CSRF

Immaginiamo di voler testare un’applicazione di banking online per verificare se è vulnerabile a un attacco CSRF. La funzione di trasferimento di denaro è un’area critica da testare. Ecco i passaggi che si potrebbero seguire:

  • Intercettazione della richiesta di trasferimento
    Utilizzando Burp Suite, intercettare la richiesta HTTP inviata quando un utente autenticato tenta di trasferire denaro. La richiesta potrebbe apparire come segue:
POST /transfer
Host: banking.com
Content-Type: application/x-www-form-urlencoded
Cookie: session_id=abcd1234
amount=1000&to_account=123456&csrf_token=xyz789
  • Rimozione del token CSRF
    Modificare la richiesta intercettata per rimuovere o alterare il token CSRF e inviare nuovamente la richiesta al server. Se il server accetta la richiesta senza il token CSRF o con un token non valido, l’applicazione è vulnerabile.
  • Simulazione di un attacco CSRF
    Creare una pagina HTML che invii la stessa richiesta POST senza il token CSRF. Esempio di form HTML:
<form action="https://banking.com/transfer" method="POST">
    <input type="hidden" name="amount" value="1000">
    <input type="hidden" name="to_account" value="123456">
    <input type="submit" value="Submit">
</form>

Caricare questa pagina con un browser dove l’utente è autenticato nell’applicazione di banking e vedere se il trasferimento avviene senza il token CSRF.

  • Verifica del Referer
    Modificare la richiesta HTTP per cambiare o rimuovere l’header Referer e inviare nuovamente la richiesta. Se l’applicazione accetta la richiesta senza un Referer valido, potrebbe essere vulnerabile a CSRF.
  • Aggiunta di intestazioni HTTP personalizzate
    Testare se l’applicazione utilizza intestazioni HTTP personalizzate per proteggersi dai CSRF, modificando la richiesta per rimuovere queste intestazioni e osservando se la richiesta viene accettata.


FAQ

  1. Che cos’è il cross-site request forgery (CSRF)?
    Il CSRF è un attacco che induce un utente autenticato a inviare richieste HTTP fraudolente senza il suo consenso, sfruttando la sua sessione attiva.
  2. Come funziona un attacco CSRF?
    Un attaccante crea una richiesta HTTP fraudolenta che viene inviata a un’applicazione web tramite l’utente autenticato, sfruttando la fiducia dell’applicazione verso l’utente.
  3. Quali sono i metodi per prevenire il CSRF?
    Utilizzo di token CSRF, intestazioni HTTP personalizzate e verifica del Referer sono alcune delle tecniche per prevenire gli attacchi CSRF.
  4. Cos’è un token CSRF?
    Un token CSRF è un valore univoco generato dal server e incluso in ogni richiesta che modifica lo stato, per verificare l’autenticità della richiesta.
  5. Come posso testare il mio sito web per vulnerabilità CSRF?
    Strumenti come OWASP ZAP e Burp Suite possono essere utilizzati per simulare attacchi CSRF e verificare la robustezza delle difese del tuo sito.
  6. Qual è un esempio comune di attacco CSRF?
    Un esempio comune è il trasferimento di denaro non autorizzato su un sito bancario tramite una richiesta POST fraudolenta inviata da un sito malevolo.
  7. Come influisce il CSRF sui web browsers?
    I web browsers, essendo il mezzo attraverso cui gli utenti interagiscono con le applicazioni web, possono essere sfruttati per inviare richieste CSRF senza che l’utente se ne accorga.
  8. Cosa significa “input type submit” in un attacco CSRF?
    “Input type submit” è un elemento HTML utilizzato per inviare form, che può essere nascosto in pagine malevole per eseguire azioni non autorizzate.
  9. Che ruolo ha il social engineering negli attacchi CSRF?
    Il social engineering viene utilizzato per ingannare gli utenti nel cliccare link o visitare pagine malevole, attivando così le richieste CSRF.
  10. Perché le applicazioni web sono vulnerabili al CSRF?
    Le applicazioni web sono vulnerabili al CSRF quando non implementano correttamente meccanismi di sicurezza come i token CSRF e le verifiche di referer, permettendo agli attaccanti di sfruttare le sessioni degli utenti autenticati.
To top