Diventa Autore per CoreTech | Scopri di più





Quali principali attacchi web possiamo aspettarci nella nuova top 10 di OWASP?

12/04/21 Coretech Blog

L'ultima edizione dell'Open Web Application Security Project Top Ten è stata rilasciata nel 2017, quattro anni dopo la precedente. Pertanto, possiamo aspettarci che la nuova versione di questo rapporto sulla sicurezza informatica uscirà nel prossimo anno. Diamo uno sguardo allo stato attuale della sicurezza delle applicazioni web sulla base della ricerca Acunetix e dell'osservazione del mercato, vediamo come si allinea con l'ultima OWASP Top 10 e prevedi cosa potrebbe significare per OWASP Top 10 2021.

A1: 2017-Iniezione → A5

La categoria Injection in OWASP Top 10 include molti diversi tipi di falle di sicurezza che possono essere facilmente rilevate da strumenti DAST professionali. Questi sono, per esempio, iniezioni SQL , iniezioni di codice , iniezioni di comando del sistema operativo , iniezioni LDAP , e molti altri. La maggior parte di queste vulnerabilità sono di gravità elevata e possono portare a problemi ancora più gravi come l'esecuzione di codice in modalità remota.

L'ultimo rapporto sulla vulnerabilità delle applicazioni Web tuttavia vede un calo del numero di iniezioni in generale. Abbiamo incluso solo due tipi principali nel rapporto: attacchi SQL injection e attacchi host header injection .

Le SQL injection, che sono i tipi più comuni e uno dei più pericolosi di iniezioni, sono in costante calo, principalmente a causa del fatto che la maggior parte degli ambienti di sviluppo e dei linguaggi di programmazione ora dispone di meccanismi adeguati per proteggersi facilmente da essi.

Nonostante il fatto che Injection fosse la categoria numero uno sia nel 2013 che nel 2017, prevediamo che nella OWASP Top 10 2021 sarà classificata come A5: 2021.

A2: 2017-Broken Authentication → A1

La categoria Broken Authentication in OWASP Top 10 si concentra su password deboli o predefinite. Sfortunatamente, tali password rimangono un grave problema per tutti i tipi di applicazioni web. Con i progressi nella tecnologia GPU, le password deboli (anche quando si utilizzano cifrature complesse) sono ora molto facili da violare utilizzando attacchi di forza bruta.

Quel che è ancora peggio è che gli amministratori insegnano le cattive abitudini ai propri utenti. Molte organizzazioni seguono le peggiori politiche possibili per la selezione delle password. Si concentrano su lettere minuscole e maiuscole, numeri e caratteri speciali, non sulla lunghezza della password stessa. Inoltre costringono gli utenti a cambiare spesso le loro password, il che fa sì che le persone utilizzino password non sicure aggiungendo caratteri o numeri prevedibili alla fine della password precedente.

Anche i misuratori di sicurezza delle password mentono agli utenti, come recentemente esposto da Paul Moore su Twitter . Una password di 10 caratteri che includeva lettere maiuscole e minuscole e numeri ha richiesto solo 5 giorni per essere decifrata (hash utilizzando SHA-256 molto sicuro). I misuratori di sicurezza della password hanno suggerito che questa password è sicura.

È molto importante seguire buone abitudini relative alle password . Inoltre, uno scanner DAST professionale come Acunetix ti aiuterà a trovare le password più comuni o predefinite se utilizzate per le tue applicazioni web. Sulla base dell'ultimo rapporto Acunetix, le password deboli nelle applicazioni web non sono così comuni, ma questo non tiene in considerazione la possibilità di infrangere facilmente password più brevi di 10 caratteri utilizzando una GPU se gli hash sono esposti.

A causa della prevalenza di questo problema, delle sue potenziali conseguenze e dell'aumento della potenza di elaborazione della GPU, prevediamo che la categoria di autenticazione interrotta sarà classificata come A1: 2021.

A3: Esposizione ai dati sensibili del 2017 → A2

La categoria di esposizione ai dati sensibili in OWASP Top 10 non si applica direttamente alle vulnerabilità web ma piuttosto alle conseguenze delle vulnerabilità web. Se un utente malintenzionato utilizza un diverso tipo di vulnerabilità Web per accedere ai dati e tali dati contengono informazioni sensibili non crittografate, le informazioni sensibili vengono immediatamente esposte.

Negli ultimi anni, abbiamo assistito a molte violazioni dei dati dovute a database esposti . Nella maggior parte di questi casi, i dati in questi database non erano nemmeno crittografati, quindi la categoria A3: 2017 è stata applicata come escalation degli attacchi. Questo è molto preoccupante, soprattutto perché la ricerca di database esposti non è un problema per gli scanner di vulnerabilità delle applicazioni web professionali.

Dato che molte aziende sembrano ancora ignorare la sicurezza dei loro database, in particolare i database Elasticsearch, prevediamo che la categoria di esposizione ai dati sensibili sarà classificata come A2: 2021.

A4: 2017-XML External Entities (XXE) → A9

La categoria XML External Entities in OWASP Top 10 era una nuova arrivata. A quel tempo, XXE era un nuovo tipo di attacco e molte risorse web non erano protette da esso. Ha sostituito Cross-site Request Forgery (CSRF) , che era presente nelle edizioni 2013 e 2010 del rapporto.

Tuttavia, i problemi relativi ai riferimenti a entità esterne nei documenti XML non sono difficili da rilevare utilizzando uno strumento professionalE. Anche la vulnerabilità non è così difficile da proteggere. 

Pertanto, prevediamo che XXE sia stato solo un picco temporaneo nel 2017 e nel 2021 sarà classificato come A9: 2021 o sarà completamente escluso dall'elenco.

A5: 2017-Broken Access Control → A4

La categoria Broken Access Control in OWASP Top 10 copre situazioni che portano a vulnerabilità come la navigazione forzata e riferimenti a oggetti diretti non sicuri . Sfortunatamente, questa categoria di vulnerabilità non può essere rilevata da alcun tipo di strumento automatico. Uno strumento può riconoscere la mancanza di un'adeguata autorizzazione ma non può indovinare se determinati account di utenti debbano avere accesso a determinate risorse o se determinate funzionalità non autorizzate siano disponibili per un utente: questo può essere giudicato solo da un essere umano.

Nelle versioni precedenti della OWASP Top 10 (2010 e 2013), questa categoria era rappresentata da due distinte: Broken Authentication e Session Management e Insecure Direct Object References. Queste categorie sono state classificate tra le prime 4 sia nell'edizione 2010 che in quella 2013 della Top 10.

A causa della difficoltà del rilevamento automatico, tali vulnerabilità spesso passano inosservate fino a quando non vengono eseguiti test di penetrazione manuali dettagliati. Pertanto, possiamo aspettarci che non verranno eliminati presto. Riteniamo che manterranno la loro posizione di forza nel 2021 e saranno classificati come A4: 2021, tornando tra i primi 4.

A6: 2017-Configurazione errata della sicurezza → A6

La categoria Errore di configurazione della sicurezza in OWASP Top 10, a differenza della maggior parte delle altre categorie di vulnerabilità in questo rapporto, si applica a tutti i problemi di sicurezza causati non da un errore di programmazione ma da un errore di configurazione. Ciò include una vasta gamma di potenziali problemi, inclusa la mancanza di hardening del sistema operativo e di software obsoleto, e si estende al server web stesso.

Gli errori di configurazione della sicurezza sono facili da individuare utilizzando uno scanner di vulnerabilità delle applicazioni Web professionale che va oltre il test del solo codice. 

Riteniamo che le configurazioni errate della sicurezza manterranno la loro posizione nella OWASP Top 10 2021 e saranno classificate come A6: 2021. Questa tendenza continuerà per tutto il percorso dal 2010 (classificato come A6) fino al 2013 (classificato come A5).

A7: 2017 Cross-Site Scripting (XSS) → A3

Abbiamo trovato curioso il motivo per cui la categoria Cross-Site Scripting in OWASP Top 10 è scesa alla posizione A7 mentre in precedenza occupava le posizioni A2 nel 2010 e A3 nel 2013. Cross-site Scripting rimane un problema molto serio, in particolare a causa della complessità di tali vulnerabilità e la difficoltà di trovare ed eliminare payload JavaScript offuscati in dati non attendibili.

Le vulnerabilità XSS compaiono ancora in una delle quattro destinazioni testate. Questa è stata anche la percentuale più alta di vulnerabilità nell'intero rapporto. Sebbene il numero sia sceso dal 33% nel 2019, rimane comunque alto.

Il problema più grande con le vulnerabilità XSS nell'era di COVID-19 è che vengono spesso utilizzate per il dirottamento della sessione utente al fine di ottenere l'accesso alle informazioni personali e agli account amministrativi nelle applicazioni web. Questo, a sua volta, può portare all'introduzione del ransomware nei sistemi aziendali, che è stata la piaga del 2020, con sempre più organizzazioni criminali che trovano questo un modo efficace per ricattare le grandi imprese.

Questo è il motivo per cui riteniamo che Cross-site Scripting tornerà in auge nell'edizione 2021 di OWASP Top 10 con una classificazione A3: 2021 prevista.

A8: 2017-Deserializzazione insicura → A10

La deserializzazione insicura è stata una nuova aggiunta alla Top 10 di OWASP nel 2017, proprio come le entità esterne XML. Questo tipo relativamente nuovo di vulnerabilità può ancora essere trovato nelle pagine web, ma con il tempo si è scoperto che appariva molto meno spesso di quanto inizialmente previsto. 

A causa del fatto che la deserializzazione insicura si verifica in casi piuttosto specifici e non è noto che abbia portato a gravi violazioni della sicurezza negli ultimi anni, prevediamo che l'edizione 2021 di OWASP Top 10 classificherà tali vulnerabilità come A10: 2021 o se ne andrà fuori dal rapporto completamente.

A9: 2017-Utilizzo di componenti con vulnerabilità note → A7

La categoria Utilizzo di componenti con vulnerabilità note è stata introdotta nella Top 10 di OWASP nel 2013 e da allora è rimasta alla posizione A9. Questa classe di vulnerabilità si riferisce alla fiducia eccessiva nel codice di terze parti e copre tutti i tipi di vulnerabilità che possono essere introdotti da tale codice.

Pertanto, la rilevabilità di tali casi dipende dalla popolarità dei componenti e dal tipo di vulnerabilità. Mentre gli strumenti di analisi della composizione del software (SCA) sono utili solo per trovare componenti vulnerabili comuni, gli strumenti DAST professionali non solo hanno controlli basati sulla firma ma consentono anche di trovare vulnerabilità in componenti meno popolari (senza firme disponibili) eseguendo attacchi fittizi.

Riteniamo che a causa della crescente complessità e importanza delle applicazioni web, sempre più sviluppatori siano semplicemente costretti a utilizzare componenti di terze parti in tutti i loro progetti. Pertanto, riteniamo che nel 2021 questa categoria sarà contrassegnata come più importante di prima e classificata come A7: 2021.

A10: Registrazione e monitoraggio insufficienti nel 2017 → A8

La categoria Registrazione e monitoraggio insufficienti è stata un'altra nuova aggiunta a OWASP Top 10 nel 2017. Sebbene questa categoria non si applichi direttamente alle vulnerabilità, è importante perché si applica alla rilevabilità delle vulnerabilità.

Riteniamo che questa categoria debba essere ampliata per includere scansioni di sicurezza insufficienti. È molto più efficace fare il primo passo per trovare le vulnerabilità prima che arrivino ai server di produzione, dove gli attacchi possono essere scoperti utilizzando la registrazione e il monitoraggio e richiedono una risposta effettiva agli incidenti.

Pertanto, speriamo che questa categoria nel 2021 venga ampliata da OWASP Top 10 per includere la scansione di sicurezza e aumentata in importanza alla posizione A8: 2021.

 


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