Diventa Autore per CoreTech | Scopri di più





Che cos'è un attacco CSRF

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.

Come prevenire la falsificazione delle richieste tra siti (CSRF) – 5 passaggi

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.

  1. Passaggio 1: allenare e mantenere la consapevolezza

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.

  1. Passaggio 2: valutare il rischio

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.

Banner

  1. Passaggio 3: utilizzare i token anti-CSRF

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.

  1. Passaggio 4: utilizzare i cookie dello stesso sito

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.

  1. Passaggio 5: scansiona regolarmente

Le vulnerabilità CSRF possono essere introdotte dai tuoi sviluppatori o tramite librerie/moduli/software esterni.


Articoli su Sicurezza

Sicurezza aziendale: da cosa è minacciata e come proteggerla?Il threat modeling per la sicurezza delle applicazioniScanner di vulnerabilità: ecco come funzionanoWeb security: 5 motivi per cui è essenziale contro i ransomwareChe cos'è DevSecOps e come dovrebbe funzionare?Test di penetrazione vs scansione delle vulnerabilitàConsiderazioni sui test di correzione delle applicazioni WebQuattro modi in cui l'analisi AppSec aiuta i tuoi professionisti DevSecOpsQuattro modi per combattere il divario di competenze di sicurezza informaticaDove i framework di cybersecurity incontrano la sicurezza webCome costruire un piano di risposta agli incidenti informaticiRendi i tuoi utenti parte della soluzione di sicurezza webSei l'unico che può proteggere le tue applicazioni webNuovo studio di settore: il 70% dei team salta i passaggi di sicurezzaConvergenza Dev-Sec: i progressi e le sfide sulla strada per garantire l'innovazioneAggiornamento FISMA: cosa sta cambiando e perché è importanteChe cos'è la sicurezza continua delle applicazioni Web?Sei l'unico che può proteggere le tue applicazioni webCos'è la sicurezza del sito Web: come proteggere il tuo sito Web dall'hackingRendi i tuoi utenti parte della soluzione di sicurezza webConvergenza Dev-Sec: la ricerca illustra i progressi per garantire l'innovazioneAggiornamento FISMA: cosa sta cambiando e perché è importanteChe cos'è la sicurezza continua delle applicazioni Web?La differenza tra XSS e CSRFNuovo studio di settore: il 70% dei team salta i passaggi di sicurezzaPrevenzione e mitigazione XSSStop ai compromessi sulla sicurezza delle applicazioni webSfatare 5 miti sulla sicurezza informaticaBasta compromessi sulla sicurezza delle applicazioni webNozioni di base sulla sicurezza web: la tua applicazione web è sicura?Che cos'è l'iniezione dell’header HTTP?Fare shift left o no?Individuazione e correzione di falle di sicurezza in software di terze partiClassi di vulnerabilità Web nel contesto delle certificazioniScripting tra siti (XSS)Che cos'è un attacco CSRFChe cos'è una SQL Injection (SQLi) e come prevenirlaAttacchi di attraversamento di directoryChe cos'è la falsificazione delle richieste lato server (SSRF)?7 migliori pratiche per la sicurezza delle applicazioni WebBlack Hat 2021: la più grande minaccia alla sicurezza informaticaÈ ben fatto? Chiedi allo sviluppatore!Scegli la soluzione di sicurezza delle applicazioni web che fa per teSicurezza fai-da-te: lo stai facendo bene?Sulla sicurezza delle applicazioni web professionali per MSSPLa cattiva comunicazione è al centro delle sfide di AppSecImpostazione e raggiungimento degli obiettivi di sicurezza delle applicazioniMetriche di sicurezza informatica per le applicazioni WebCome evitare attacchi alla supply chainPerché la maggior parte delle misure di sicurezza delle applicazioni fallisceVuoi che la tua sicurezza sia costruita su scuse?Cos'è SCA e perché ne hai bisognoLa scansione ad hoc non è sufficienteEsposizione dei dati sensibili: come si verificano le violazioniHai paura dei test di sicurezza nell'SDLC?Vantaggi di Web Asset DiscoveryStrumenti di scansione delle vulnerabilità: perché non open source?Protezione WAF - Ottieni il massimo dal tuo firewall per applicazioni webL'errore di comunicazione è al centro delle sfide di AppSecDebugger remoti come vettore di attaccoDAST è una parte essenziale di un programma completo per la sicurezza delle applicazioniCome difendersi dagli attacchi recenti su Microsoft Exchange5 principali vantaggi dei primi test di sicurezzaTecniche di attacco Denial-of-Service con avvelenamento della cacheQuali principali attacchi web possiamo aspettarci nella nuova top 10 di OWASP?Hack di SolarWindsPillole di Sicurezza | Episodio 38Pillole di Sicurezza | Episodio 37Perché gli sviluppatori evitano la sicurezza e cosa puoi fare al riguardoPillole di Sicurezza | Episodio 36Cos'è l'attacco RUDYCos'è la navigazione forzataCome gli scanner trovano le vulnerabilitàPillole di Sicurezza | Episodio 34Pillole di Sicurezza | Episodio 35Come eseguire il benchmark di uno scanner di vulnerabilità Web?Pillole di Sicurezza | Episodio 33Pillole di Sicurezza | Episodio 325 proposte di vendita comuni sulla sicurezza delle applicazioni web5 motivi per non fare affidamento sui programmi BountyPillole di Sicurezza | Episodio 315 motivi per cui la sicurezza web è importante quanto la sicurezza degli endpointPillole di Sicurezza | Episodio 305 motivi per cui la sicurezza web è importante per evitare il ransomwarePillole di Sicurezza | Episodio 293 motivi per cui DAST è il migliore per la sicurezza delle applicazioni WebPillole di Sicurezza | Episodio 28Pillole di Sicurezza | Episodio 27Pillole di Sicurezza | Episodio 24Pillole di Sicurezza | Episodio 25Pillole di Sicurezza | Episodio 21Pillole di Sicurezza | Episodio 22Pillole di Sicurezza | Episodio 20Pillole di Sicurezza | Episodio 17Il flag HttpOnly: protezione dei cookie da XSSPillole di Sicurezza | Episodio 16Il Bug Heartbleed – I vecchi Bug sono duri a morirePillole di Sicurezza | Episodio 15Pillole di Sicurezza | Episodio 14Pillole di Sicurezza | Episodio 13Pillole di Sicurezza | Episodio 12Pillole di Sicurezza | Episodio 11Pillole di Sicurezza | Episodio 10Sicurezza delle reti: gli hacker puntano CitrixCyber hacking: la Germania chiede l’intervento dell’UESicurezza informatica: Cisco rilascia aggiornamentiOcchio al cryptojacking: malware infiltrato in Docker HubSIGRed: bug di sistema in Windows Server scovato dopo 17 anniPillole di Sicurezza | Episodio 9Summit Live - Disponibili le registrazioni delle live di MonteleoneCriminalità informatica: Schmersal sventa un cyber-attaccoPillole di Sicurezza | Episodio 8Pillole di Sicurezza | Episodio 7Analisi pratica dei rischi per il SysAdmin, DevOps e Dev | Summit LivePillole di Sicurezza | Episodio 6Pillole di Sicurezza | Episodio 5Pillole di Sicurezza | Episodio 4Pillole di Sicurezza | Episodio 3Pillole di Sicurezza | Episodio 2Pillole di Sicurezza | Episodio 1Pillole di Sicurezza | Episodio 23