Diventa Autore per CoreTech | Scopri di più
18/11/21 CoreTech Blog
Cross-site Request Forgery (CSRF/XSRF), a volte chiamato anche surf in mare o session riding , si riferisce a un attacco contro applicazioni web autenticate che utilizzano i cookie. L'aggressore è in grado di indurre la vittima a fare una richiesta che la vittima non aveva intenzione di fare. Pertanto, l'attaccante abusa della fiducia che un'applicazione web ha per il browser della vittima. Sebbene gli attacchi Cross-site Request Forgery (CSRF) non forniscano a un utente malintenzionato la risposta restituita dal server, un utente malintenzionato potrebbe causare una discreta quantità di danni, soprattutto se associato a un attacco di social engineering ben congegnato agli utenti amministrativi.
Cross-site Request Forgery (CSRF) è un tipo di attacco confuso del vice, che sfrutta l'autenticazione e l'autorizzazione della vittima quando una richiesta contraffatta viene inviata al server web. Pertanto, una vulnerabilità CSRF che colpisce gli utenti con privilegi elevati, come gli amministratori, potrebbe comportare una compromissione completa dell'applicazione. Durante un attacco CSRF riuscito, il browser Web della vittima viene ingannato da un sito Web dannoso in un'azione indesiderata: invia richieste HTTP all'applicazione Web come previsto dall'attaccante. Normalmente tale richiesta comporterebbe l'invio di moduli presenti sull'applicazione web per alterare alcuni dati.
All'invio di una richiesta HTTP (legittima o meno), il browser della vittima includerà l'intestazione del cookie. I cookie vengono in genere utilizzati per memorizzare l'identificatore di sessione di un utente in modo che l'utente non debba inserire le proprie credenziali di accesso per ogni richiesta, il che sarebbe ovviamente poco pratico. Se la sessione di autenticazione della vittima è memorizzata in un cookie di sessione ancora valido (non è necessario che una finestra/scheda del browser sia aperta) e se l'applicazione è vulnerabile a Cross-site Request Forgery (CSRF), l'attaccante può sfruttare CSRF per avviare qualsiasi richiesta dannosa desiderata contro il sito Web e il codice lato server non è in grado di distinguere se si tratta di richieste legittime.
Gli attacchi CSRF possono, ad esempio, essere utilizzati per compromettere l'online banking costringendo la vittima a effettuare un'operazione che coinvolga il proprio conto bancario. CSRF può anche facilitare Cross-site Scripting (XSS). Pertanto, CSRF dovrebbe essere trattato come un serio problema di sicurezza delle applicazioni Web, anche se attualmente non è incluso nella OWASP Top 10.
Le vulnerabilità Cross-site Request Forgery (CSRF) sono pericolose in parte perché prevenirle non è così facile. Esistono diversi metodi che è possibile utilizzare per evitarli, ma non tutti sono efficaci in tutti gli scenari. Oltre a due metodi considerati i più efficaci, ci sono alcuni principi strategici generali che dovresti seguire per mantenere sicura la tua applicazione web.
Per mantenere sicura la tua applicazione web, tutti coloro che sono coinvolti nella creazione dell'applicazione web devono essere consapevoli dei rischi associati alle vulnerabilità CSRF. Dovresti fornire una formazione sulla sicurezza adeguata a tutti i tuoi sviluppatori, personale addetto al controllo qualità, DevOps e SysAdmins. Puoi iniziare facendo riferimento a questa pagina.
e vulnerabilità CSRF non si applicano ai contenuti pubblici. Sono pericolosi solo quando è richiesta l'autenticazione. Pertanto, puoi ignorare questo rischio se hai solo contenuti pubblici sul tuo sito web. Tuttavia, se disponi di un'applicazione Web con account utente, fai molta attenzione. Considera CSRF come un grosso rischio se disponi di un'applicazione di e-commerce.
I token anti-CSRF sono considerati il metodo più efficace di protezione contro CSRF. Utilizza un'implementazione testata come CSRFGuard per Java o CSRFProtector per PHP per implementare i token anti-CSRF. Sviluppa il tuo meccanismo solo se non ne esiste uno esistente per il tuo ambiente.
Imposta l'attributo SameSite dei tuoi cookie su Strict. Se ciò interrompe la funzionalità della tua applicazione web, imposta l'attributo SameSite su Lax ma mai su None. Non tutti i browser supportano ancora i cookie SameSite, ma la maggior parte lo fa. Usa questo attributo come protezione aggiuntiva insieme ai token anti-CSRF.
Le vulnerabilità CSRF possono essere introdotte dai tuoi sviluppatori o tramite librerie/moduli/software esterni.
