Utilizza una libreria di sviluppo che implementi token anti-CSRF

Utilizza una libreria di sviluppo che implementi token anti-CSRF

Il Cross-Site Request Forgery (CSRF) è un tipo di attacco che si verifica quando un sito Web, un'e-mail, un blog, un messaggio istantaneo o un programma dannoso fa sì che il browser Web di un utente esegua un'azione indesiderata su un sito affidabile quando l'utente è autenticato. Un attacco CSRF funziona perché le richieste del browser includono automaticamente tutti i cookie, compresi quelli di sessione. Pertanto, se l'utente è autenticato al sito, quest'ultimo non è in grado di distinguere tra le richieste legittime autorizzate e le richieste autenticate contraffatte. Questo attacco viene sventato se si utilizza meccanismo di autenticazione adeguata, il che implica la necessità di un meccanismo di sfida-risposta che verifichi l'identità e l'autorità del richiedente.

L'impatto di un attacco CSRF riuscito è limitato alle capacità esposte dall'applicazione vulnerabile e ai privilegi dell'utente. Ad esempio, questo attacco potrebbe portare a un trasferimento di fondi, alla modifica di una password o a un acquisto con le credenziali dell'utente.

In breve, per difendersi dal CSRF è necessario seguire i seguenti principi:

  • Verificare se il framework di sviluppo utilizzato dispone di una protezione CSRF integrata e utilizzarla;

  • Se il framework non dispone di una protezione CSRF integrata, aggiungere token CSRF a tutte le richieste di modifica dello stato (richieste che causano azioni sul sito) e convalidarle nel backend;

  • Per i software statici, utilizzare lo schema del token sincronizzatore;

  • Per i software stateless, utilizzare cookie a doppio invio:

Ricordate che qualsiasi vulnerabilità Cross-Site Scripting (XSS) può essere utilizzata per sconfiggere tutte le tecniche di mitigazione CSRF!

Mitigazione basata sui token

Lo schema dei token di sincronizzazione è uno dei metodi più popolari e consigliati per mitigare il CSRF.

Le difese con token sincronizzatore sono state integrate in molti framework. Si raccomanda vivamente di verificare se il framework in uso dispone di un'opzione per ottenere la protezione CSRF per impostazione predefinita prima di provare a costruire un sistema di generazione di token personalizzato. Ad esempio, .NET ha una protezione integrata che aggiunge un token alle risorse vulnerabili al CSRF. L'utente è responsabile della corretta configurazione (come la gestione delle chiavi e dei token) prima di utilizzare queste protezioni CSRF integrate che generano token per proteggere le risorse vulnerabili CSRF.

Schema del token del sincronizzatore

I token CSRF devono essere generati lato server. Possono essere generati una volta per sessione utente o per ogni richiesta. I token per richiesta sono più sicuri di quelli per sessione, poiché l'intervallo di tempo in cui un aggressore può sfruttare i token rubati è minimo. Tuttavia, ciò può comportare problemi di usabilità. Ad esempio, la funzionalità del pulsante "Indietro" del browser è spesso ostacolata perché la pagina precedente può contenere un token non più valido. L'interazione con questa pagina precedente provocherà un evento di sicurezza CSRF falso positivo sul server. Nell'implementazione del token per sessione, dopo la generazione iniziale del token, il valore viene memorizzato nella sessione e utilizzato per ogni richiesta successiva fino alla scadenza della sessione.

Quando una richiesta viene emessa dal client, il componente lato server deve verificare l'esistenza e la validità del token nella richiesta rispetto al token trovato nella sessione dell'utente. Se il token non è stato trovato nella richiesta o se il valore fornito non corrisponde a quello della sessione utente, la richiesta deve essere interrotta. Si devono prendere in considerazione anche azioni aggiuntive, come la registrazione dell'evento come un potenziale attacco CSRF in corso.

I token CSRF devono essere:

  1. Unici per sessione utente;

  2. segreti;

  3. imprevedibili (valore casuale generato da un metodo sicuro).

I token CSRF prevengono il CSRF perché senza token l'attaccante non può creare richieste valide al server backend.

I token CSRF non devono essere trasmessi utilizzando i cookie.

Il token CSRF può essere aggiunto attraverso campi nascosti, intestazioni e può essere utilizzato con moduli e chiamate AJAX. Assicurarsi che il token non venga trasmesso nei log del server o nell'URL.