Open Web App Security Project gestisce un elenco dei problemi più urgenti per la sicurezza delle applicazioni Web. Viene aggiornato a intervalli regolari.
Dopo aver letto questo articolo sarai in grado di:
Argomenti correlati
Sicurezza delle applicazioni Web
Attacco brute-force
Violazione dei dati
Attacco di interposizione
Attacco di buffer overflow
Abbonati a theNET, il riepilogo mensile di Cloudflare sulle tematiche più discusse in Internet.
Copia link dell'articolo
Open Web app Security Project, o OWASP, è un'organizzazione internazionale senza scopo di lucro dedicata alla sicurezza delle applicazioni Web. Uno dei principi fondamentali di OWASP è che tutti i loro materiali siano disponibili gratuitamente e facilmente accessibili sul proprio sito Web, consentendo a chiunque di migliorare la sicurezza della propria applicazione Web. I materiali che offrono includono documentazione, strumenti, video e forum. Forse il loro progetto più noto è la Top 10 di OWASP.
La Top 10 OWASP è un rapporto regolarmente aggiornato che delinea i problemi di sicurezza per la sicurezza delle applicazioni Web, concentrandosi sui 10 rischi più critici. Il report è redatto da un team di esperti di sicurezza provenienti da tutto il mondo. OWASP considera la Top 10 come un "documento di sensibilizzazione" e raccomanda a tutte le aziende di integrare il report nei propri processi al fine di ridurre al minimo e/o mitigare i rischi per la sicurezza.
Di seguito sono indicati i rischi per la sicurezza riportati nel report Top 10 2021 di OWASP:
Controllo degli accessi si riferisce a un sistema che controlla l'accesso a informazioni o funzionalità. Il controllo degli accessi interrotto consente agli autori di un attacco di aggirare l'autorizzazione ed eseguire attività come se fossero utenti privilegiati, ad esempio amministratori. Ad esempio, un'applicazione Web potrebbe consentire a un utente di modificare l'account a cui ha effettuato l'accesso semplicemente modificando parte di un URL, senza alcuna altra verifica.
Il controllo degli accessi può essere protetto facendo in modo che un'applicazione Web utilizzi il token di autorizzazione* e imposti rigorosi controlli su questo.
*Molti servizi rilasciano token di autorizzazione quando gli utenti effettuano l'accesso. Ogni richiesta con privilegi che un utente effettua richiederà la presenza del token di autorizzazione. Questo è un modo sicuro per garantire che l'utente sia chi dice di essere, senza dover immettere costantemente le proprie credenziali di accesso.
Se le applicazioni Web non proteggono i dati sensibili, quali informazioni finanziarie e password, utilizzando la crittografia, gli aggressori possono accedere a tali dati e venderli o utilizzarli per scopi illeciti. Possono rubare informazioni sensibili anche utilizzando un attacco di interposizione.
Il rischio di esposizione dei dati può essere ridotto al minimo crittografando tutti i dati sensibili, autenticando tutte le trasmissioni e disabilitando il caching* di tutte le informazioni sensibili. Inoltre, gli sviluppatori di applicazioni Web dovrebbero assicurarsi di non archiviare inutilmente dati sensibili.
*Il caching è la pratica di memorizzare temporaneamente i dati per riutilizzarli. Ad esempio, i browser Web spesso memorizzano nella cache le pagine Web in modo che se un utente visita nuovamente tali pagine entro un intervallo di tempo fisso, il browser non le debba recuperare dal Web.
Gli attacchi di injection si verificano quando vengono inviati dati non attendibili a un interprete di codice tramite l'input di un modulo o un altro invio di dati a un'applicazione Web. Ad esempio, un autore di un attacco potrebbe inserire il codice del database SQL in un modulo che prevede un nome utente in chiaro. Se l'input del modulo non è protetto correttamente, potrebbe comportare l'esecuzione di quel codice SQL. Questo è noto come attacco di SQL injection.
La categoria Iniezione comprende anche gli attacchi cross-site scripting (XSS), che in precedenza, nel rapporto del 2017, erano una categoria a sé stante. Le strategie di mitigazione per il cross-site scripting includono l'escape di richieste HTTP non attendibili, nonché l'utilizzo di moderni framework di sviluppo Web come ReactJS e Ruby on Rails, che forniscono una protezione integrata dal cross-site scripting.
In generale, gli attacchi di tipo Injection possono essere prevenuti convalidando e/o sanificando i dati inviati dall'utente. (Convalida significa rifiutare i dati dall'aspetto sospetto, mentre la bonifica si riferisce alla pulizia delle parti dei dati dall'aspetto sospetto). Inoltre, un amministratore di database può impostare controlli per ridurre al minimo la quantità di informazioni che un attacco di injection può esporre.
Scopri di più su come prevenire le SQL injection.
La progettazione non sicura include una serie di punti deboli che possono essere incorporati nell'architettura di un'applicazione. Si concentra sulla progettazione di un'applicazione, non sulla sua implementazione. OWASP elenca l'uso di domande di sicurezza (ad esempio, "In quale strada sei cresciuto?") per il recupero della password come esempio di un flusso di lavoro progettato in modo non sicuro. Indipendentemente da quanto perfettamente un flusso di lavoro del genere venga implementato dai suoi sviluppatori, l'applicazione sarà comunque vulnerabile, perché più di una persona potrebbe conoscere la risposta a queste domande di sicurezza.
L'utilizzo della modellazione delle minacce prima dell'implementazione di un'applicazione può aiutare ad attenuare questi tipi di vulnerabilità.
L'errata configurazione della sicurezza è la vulnerabilità più comune ed è spesso il risultato dell'utilizzo di configurazioni predefinite o della visualizzazione di errori eccessivamente dettagliati. Ad esempio, un'applicazione potrebbe mostrare a un utente errori eccessivamente descrittivi che potrebbero rivelare vulnerabilità nell'applicazione. Questo può essere mitigato rimuovendo tutte le funzionalità inutilizzate nel codice e garantendo che i messaggi di errore siano più generali.
La categoria "Configurazione errata della sicurezza" include l'attacco XML External Entities (XEE), che nel rapporto del 2017 era in precedenza una categoria a sé stante. Questo è un attacco contro un'applicazione Web che analizza l'input* XML. Questo input può fare riferimento a un'entità esterna, tentando di sfruttare una vulnerabilità nel parser. Un'"entità esterna" in questo contesto si riferisce a un'unità di archiviazione, come un disco rigido. Un parser XML può essere indotto con l'inganno a inviare dati a un'entità esterna non autorizzata, che può passare dati sensibili direttamente a un autore di un attacco. I modi migliori per prevenire gli attacchi XEE consistono nel fare in modo che le applicazioni Web accettino un tipo di dati meno complesso, come JSON, o almeno per patch ai parser XML e disabilitare l'uso di entità esterne in un'applicazione XML.
*XML o Extensible Markup Language è un linguaggio di markup concepito per essere leggibile sia dall'uomo che dalla macchina. A causa della sua complessità e vulnerabilità di sicurezza, è ora in fase di graduale abbandono in molte applicazioni Web.
Molti sviluppatori Web moderni utilizzano componenti come librerie e framework nelle loro applicazioni Web. Questi componenti sono frammenti di software che aiutano gli sviluppatori a evitare il lavoro ridondante e forniscono le funzionalità necessarie; esempi comuni includono framework front-end come React e librerie più piccole utilizzate per aggiungere icone di condivisione o test a/b. Alcuni autori di attacchi cercano vulnerabilità in questi componenti che possono quindi sfruttare per orchestrare gli attacchi. Alcuni dei componenti più popolari sono utilizzati su centinaia di migliaia di siti Web; un autore di un attacco che trova una falla nella sicurezza in uno di questi componenti potrebbe lasciare centinaia di migliaia di siti vulnerabili da sfruttare.
Gli sviluppatori di componenti spesso offrono patch di sicurezza e aggiornamenti per colmare le vulnerabilità note, ma gli sviluppatori di applicazioni Web non sempre dispongono delle versioni corrette o più recenti dei componenti in esecuzione sulle loro applicazioni. Per ridurre al minimo il rischio di eseguire componenti con vulnerabilità note, gli sviluppatori dovrebbero rimuovere i componenti inutilizzati dai loro progetti e assicurarsi di ricevere componenti aggiornati da una fonte attendibile.
Le vulnerabilità nei sistemi di autenticazione (accesso) possono fornire agli autori di un attacco l'accesso agli account utente e persino la possibilità di compromettere un intero sistema utilizzando un account amministratore. Ad esempio, un autore di un attacco può sottrarre un elenco con migliaia di combinazioni di nome utente e password note ottenute durante una violazione dei dati e utilizzare uno script per provare tutte quelle combinazioni su un sistema di accesso per scoprire se una di queste può essere violata con successo.
Alcune strategie per mitigare le vulnerabilità di autenticazione richiedono l'autenticazione a due fattori (2FA) e la limitazione o il ritardo dei tentativi di accesso ripetuti utilizzando la limitazione della frequenza.
Oggi molte applicazioni si affidano a plug-in di terze parti e altre fonti esterne per il loro funzionamento e non sempre verificano che gli aggiornamenti e i dati provenienti da tali fonti non siano stati manomessi e provengano dalla posizione prevista. Ad esempio, un'applicazione che accetta automaticamente gli aggiornamenti da una fonte esterna potrebbe essere vulnerabile a un aggressore che carica i propri aggiornamenti dannosi, che verrebbero poi distribuiti a tutte le installazioni di quell'applicazione. Questa categoria include anche gli exploit di deserializzazione non sicura: questi attacchi sono il risultato della deserializzazione di dati provenienti da fonti non attendibili e possono avere gravi conseguenze, come gli attacchi DDoS e gli attacchi di esecuzione di codice remoto.
Per garantire che l'integrità dei dati e degli aggiornamenti non venga violata, gli sviluppatori di applicazioni dovrebbero utilizzare firme digitali per verificare gli aggiornamenti, controllare le loro catene di fornitura software e assicurarsi che le pipeline di integrazione continua/distribuzione continua (CI/CD) abbiano un controllo di accesso rigoroso e siano configurate correttamente.
Molte applicazioni Web non stanno adottando misure sufficienti per rilevare le violazioni dei dati. Il tempo medio di rilevamento di una violazione è di circa 200 giorni dopo che si è verificata. Questo dà ad autore di un attacco molto tempo per causare danni prima che ci sia una risposta. OWASP consiglia agli sviluppatori Web di implementare la registrazione e il monitoraggio, nonché un piano di risposta agli incidenti per garantire che siano informati degli attacchi alla propria applicazione.
La falsificazione delle richieste lato server (SSRF) è un attacco in cui qualcuno invia una richiesta URL a un server, che fa sì che il server recuperi una risorsa inaspettata, anche se tale risorsa è altrimenti protetta. Un autore di un attacco potrebbe, ad esempio, inviare una richiesta per www.example.com/super-secret-data/, anche se gli utenti web non dovrebbero essere in grado di raggiungere quella posizione e di accedere a dati estremamente segreti tramite la risposta del server.
Esistono diverse possibili misure di mitigazione per gli attacchi SSRF e una delle più importanti è convalidare tutti gli URL provenienti dai client. Gli URL non validi non dovrebbero generare una risposta diretta e non elaborata dal server.
Per uno sguardo più tecnico e approfondito alla Top 10 di OWASP, consulta il report ufficiale.