Ultima modifica:
La fondazione OWASP e la OWASP Top 10
Tempo di lettura stimato: 15 min
1 Cos'è la OWASP?
L'Open Web Application Security Project (OWASP) è una fondazione senza scopo di lucro dedicata al miglioramento e alla diffusione di consapevolezza sulla sicurezza del software. Come ben sappiamo, gli attacchi informatici al giorno d'oggi sono sempre più soventi e sviluppati. Per gli sviluppatori (e per gli addetti alla messa in sicurezza) restare al passo con le ultime tecniche, tecnologie e "best practices" non è semplice, ed ecco perché quindi è nata e si è sviluppata la OWASP: aiutare la comunità tecnologica a migliorare la sicurezza del software, fornendo strumenti (vedi Zed Attack Proxy), guide (Web Security Testing Guide e Mobile Security Testing Guide) e conoscenze pratiche.
2 Top 10 Web Application Security Risks (2021)
La OWASP Top 10 Web Application Security Risks, meglio nota come OWASP Web Top 10, è un documento volto alla diffusione di consapevolezza sulle vulnerabilità più diffuse nei tempi moderni. Da quanto è nato si è presto trasformato in uno standard per l'AppSec, nonostante esso documenti non solo falle tecniche - facilmente testabili anche con tool automatici - ma anche falle procedurali, come una scarsa progettazione security-oriented o l'insufficiente monitoraggio di log.
La OWASP Web Top 10 è stata recentemente aggiornata a seguito dell'avvento di nuove vulnerabilità exploitate "in the wild" e a seguito di una maggiore consapevolezza rivolta al mondo della sicurezza, molto diversa da come veniva affrontata nel 2017.
L'attuale OWASP Web Top 10 (2021) comprende le seguenti categorie di vulnerabilità:
2.1 A01:2021 - Broken Access Control
La categoria Broken Access Controll comprende tutte quelle vulnerabilità che permettono ad utenti non autorizzati di accedere ad informazioni, aree o contenuti riservati ai quali normalmente non avrebbero accesso. E' una delle vulnerabilità più comuni al giorno d'oggi ed è dovuta a configurazioni errate o mancanti dell'access controll, la componente che fa rispettare la policy in modo che gli utenti non possano agire al di fuori dei permessi previsti.
Tra le vulnerabilità più comuni di questa categoria troviamo:
- Violazione del principio del minimo privilegio o deny by default, dove l'accesso dovrebbe essere concesso solo per particolari capabilities, ruoli o utenti, ma è disponibile a chiunque.
- Bypassare i controlli di accesso modificando l'URL (modifica dei parametri o navigazione forzata), lo stato interno dell'applicazione o la pagina HTML, o utilizzando uno strumento di attacco che modifica le richieste API.
- Permettere la visualizzazione o la modifica dell'account di qualcun altro, fornendo il suo identificatore unico (insecure direct object references)
- Accesso all'API con controlli di accesso mancanti per POST, PUT e DELETE.
- Elevazione dei privilegi. Agire come un utente senza essere loggato o agire come amministratore quando si è svolto il login come utente base.
- Manipolazione dei metadati, come la riproduzione o la modifica di un JSON Web Token (JWT), o un cookie o un campo nascosto manipolati per elevare i privilegi o abusare dell'invalidazione del JWT.
- La configurazione errata di CORS permette l'accesso all'API da origini non autorizzate/non fidate.
- Forzare la navigazione verso pagine autenticate come utente non autenticato o a pagine privilegiate come utente base.
2.2 A02:2021 - Cryptographic Failures
Questa categoria riguarda tutte quelle vulnerabilità relative alla mal implementazione, o addirittura all'assenza, di sistemi crittografici. Certe tipologie di dato, sia che vengano salvati in locale, sia che vengano scambiati tra client e server, necessitano di protezione: è il caso di password, numeri di carte di credito, documenti sanitari, ecc. Fallire nel proteggere questi dati è un problema e tutte le vulnerabilità di questa categoria riguardano questo tipo di problematica.
Tra le principali casistiche troviamo:
Tra le principali casistiche troviamo:
- I dati sono trasmessi in chiaro? Questo riguarda protocolli come come HTTP, SMTP, FTP che utilizzano anche aggiornamenti TLS come STARTTLS. Il traffico internet esterno è pericoloso. Verificare tutto il traffico interno, ad es, tra load balancer, server web o sistemi back-end.
- Ci sono algoritmi o protocolli crittografici vecchi o deboli utilizzati di default o nel codice più vecchio?
- Sono utilizzate chiavi crittografiche predefinite, chiavi crittografiche deboli generate o riutilizzate, o manca un'adeguata gestione o rotazione delle chiavi? Le chiavi crittografiche sono nei repository del codice sorgente?
- La crittografia non è applicata, ad esempio, ci sono header HTTP (browser) direttive di sicurezza o altri header mancanti?
- Il certificato ricevuto dal server e la chain of trust sono validati correttamente?
- I vettori di inizializzazione sono ignorati, riutilizzati o non generati in modo sufficientemente sicuro per il funzionamento di una certa modalità crittografica? È in uso una modalità crittografica insicura come l'ECB? Viene utilizzata la semplice crittografia quando è invece necessario abbinarla anche ad un meccanismo di autenticazione?
- Le password vengono usate come chiavi crittografiche senza l'utilizzo di una funzione di derivazione della chiave basata sulla password?
- Viene utilizzata una funzione di randomness che non è stata progettata per soddisfare i requisiti crittografici? Anche se viene utilizzata la funzione appropriata, il seed deve essere inizializzato dallo sviluppatore, e se no, lo sviluppatore ha sovrascritto la funzionalità di seed forte incorporata con una che manca di sufficiente entropia/imprevedibilità?
- Vengono utilizzate funzioni hash deprecate come MD5 o SHA1, o vengono utilizzate funzioni hash non crittografiche quando sono necessarie funzioni hash crittografiche?
- Sono utilizzati metodi deprecati di padding crittografico come PKCS#1 v1.5?
- I messaggi di errore crittografici o le informazioni ottenute da un side channel sono sfruttabili, per esempio per svolgere attacchi padding oracle?
2.3 A03:2021 - Injection
La categoria Injection comprende tutte quelle vulnerabilità per cui l'exploitation richiede di iniettare qualche sorta di carattere speciale o payload, come nel caso di vulnerabilità SQL Injection o XSS. Nello specifico un'app è vulnerabile a injection quanto
- I dati forniti dall'utente non sono validati, filtrati o sanificati dall'applicazione.
- Le query dinamiche o le chiamate non parametrizzate senza escaping contestuale vengono passate direttamente all'interprete.
- Input malevolo viene usato all'interno di parametri di ricerca di un ORM (object-relational mapping) per estrarre ulteriori record sensibili.
- Input malevolo viene usato in modo diretto o concatenato. Le query SQL o i comandi includono i dati ostili nelle query dinamiche, nei comandi o nelle stored procedure.
Tra le varie vulnerabilità che ricadono in questa categorie, le più conosciute sono indubbiamente XSS e SQL Injection, ma sono comprese anche Command Injection, LDAP Injection, SSTI, Path Traversal, LFI e RFI (e ancora altre).
2.4 A04:2021 - Insecure Design
Insecure Design è una nuova categoria introdotta nel 2021 con un focus molto specifico sulla progettazione di applicazioni sicure e sui rischi relativi a difetti di architettura. Un design insicuro non può essere corretto con un'implementazione perfetta, poiché per definizione i controlli di sicurezza necessari non sono mai stati creati per difendersi da attacchi specifici.
La categoria riguarda dunque non solo aspetti tecnici, ma anche e soprattutto una forma mentis da rispettare in fase di ideazione di applicazioni e apparati, con un focus incentrato alla sicurezza. Invito tutti quanti a leggere la pagina ufficiale della OWASP in modo da avere maggiori dettagli in merito a questa nuova categoria di vulnerabilità:
La categoria riguarda dunque non solo aspetti tecnici, ma anche e soprattutto una forma mentis da rispettare in fase di ideazione di applicazioni e apparati, con un focus incentrato alla sicurezza. Invito tutti quanti a leggere la pagina ufficiale della OWASP in modo da avere maggiori dettagli in merito a questa nuova categoria di vulnerabilità:
2.5 A05:2021 - Security Misconfiguration
Fanno parte di questa categoria tutte le vulnerabilità e i bug riconducibili ad errori di configurazione. Con una tendenza al software sempre più configurabile, non è sorprendente vedere questa categoria salire rispetto agli anni passati. Fanno ora parte di questa famiglia anche le vulnerabilità relative ad "Improper Restriction of XML External Entity" (prima una categoria a parte), mentre ne fanno sempre parte tutte le altre falle per cui:
- Manca l'hardening di sicurezza appropriato in qualsiasi parte dello stack applicativo o permessi configurati in modo improprio sui servizi cloud.
- Sono abilitate o installate funzioni non necessarie (ad es. porte, servizi, pagine, account o privilegi non necessari).
- Gli account di default sono ancora abilitati e presentano password predefinite.
- A seguito di condizioni di errore, vengono rivelate agli utenti stack traces o altri messaggi di errore troppo verbosi.
- Per i sistemi aggiornati, le ultime funzionalità di sicurezza sono disabilitate o non configurate in modo adeguato.
- Le impostazioni di sicurezza negli application server, nei framework (ad esempio, Struts, Spring, ASP.NET), nelle librerie, database, ecc. non sono configurate su valori sicuri.
- Il server non invia header o direttive di sicurezza o non sono impostati su valori sicuri.
2.6 A06:2021 - Vulnerable and Outdated Components
Questa categorie riguarda tutte le falle legate all'utilizzo di librerie e componenti vulnerabili o obsoleti all'interno di applicazioni e siti web.
La principali vulnerabilità si presentano se:
- Se il software è vulnerabile, non supportato o non aggiornato.
- Se non si fa la scansione delle vulnerabilità regolarmente
- Se non si corregge o non si aggiorna la piattaforma sottostante, i framework, e le dipendenze in modo tempestivo e basato sul rischio.
- Se gli sviluppatori non testano la compatibilità delle librerie aggiornate, nuove o patchate.
- Se i componenti non vengono configurati in modo sicuro (05:2021-Security Misconfiguration).
2.7 A07:2021 - Identification and Authentication Failures
In passato la categoria era nota come Broken Authentication, ora riguarda non solo tutte le falle riguardo la conferma dell'identità, dell'autenticazione e della gestione della sessione dell'utente, ma anche problematiche legate ai meccanismi di autorizzazione implementati da un applicativo.
Le principali debolezze sui meccanismi di autenticazione risiedono quanto l'applicazione:
- Consente attacchi come il credential stuffing.
- Consente il bruteforce
- Consente password predefinite come "Password1" o "admin/admin".
- Utilizza processi di recupero credenziali deboli o inefficaci e password dimenticata.
- Utilizza archivi dati di password in testo normale, crittografate o con hash debole
- Presenta un'autenticazione a più fattori mancante o inefficace (2FA)
- Non invalida correttamente gli ID di sessione. Le sessioni utente o i token di autenticazione (principalmente token SSO) non vengono invalidati correttamente durante il logout o un periodo di inattività.
2.8 A08:2021 - Software and Data Integrity Failures
Nuova categoria nata nel 2021, questa sezione raggruppa tutte le vulnerabilità relative alla verifica dell'integrità di aggiornamenti software, dati critici, e pipeline di CI/CD. Un esempio è quando un'applicazione si affida a plugin, librerie o moduli da fonti, repository e content delivery network (CDN) non attendibili. Una pipeline CI/CD insicura può aprire la porta ad accessi non autorizzati, codice dannoso o compromissione completa del sistema. Molte applicazioni, inoltre, ora includono funzionalità di auto-aggiornamento, dove gli aggiornamenti vengono scaricati senza una sufficiente verifica, aprendo le porte a possibili nuovi scenari d'attacco.
Le CWE (Common Weakness Enumeration) caratteristiche di questa categoria sono:
Le CWE (Common Weakness Enumeration) caratteristiche di questa categoria sono:
- CWE-829: Inclusion of Functionality from Untrusted Control Sphere
- CWE-494: Download of Code Without Integrity Check
- CWE-502: Deserialization of Untrusted Data.
https://owasp.org/Top10/it/A08_2021-Software_and_Data_Integrity_Failures/
2.9 A09:2021 - Security Logging and Monitoring Failures
Questa categoria è una delle più difficili da testare e da verificare. Non esistono molte CVE/CVSS legati a tali problematiche, inoltre per verificare tali problematiche bisogna affidarsi a dati statistici (numero di attacchi identificati, numero di incidenti gestiti, ecc.) o ad informazioni "per sentito dire" (dichiarazioni, audit, ecc.).
Tale categoria serve quindi ad identificare e sanare eventuali problematiche lato monitoraggio, detenzione, risposta attiva e logging delle minacce. Queste attività vengono considerate "deboli" quando:
Tale categoria serve quindi ad identificare e sanare eventuali problematiche lato monitoraggio, detenzione, risposta attiva e logging delle minacce. Queste attività vengono considerate "deboli" quando:
- Gli eventi verificabili, come i login, i login falliti e le transazioni ad alto valore, non vengono registrati.
- Warning ed errori non generano messaggi di log, oppure sono inadeguati o poco chiari.
- I log di applicazioni e API non sono monitorati per attività sospette.
- I file di log vengono memorizzati solo localmente.
- Non sono presenti o sono inefficaci le soglie di allarme e processi di escalation della risposta
- I penetration test e le scansioni da parte di strumenti DAST (Dynamic Application Security Testing) (come OWASP ZAP) non attivano nessun allarme.
- L'applicazione non è in grado di rilevare, svolgere escalation o avvisare per gli attacchi attivi in real-time o quasi in real-time.
2.10 A10:2021 - Server-Side Request Forgery
Le vulnerabilità relative a Server Side Request Forgery sono in forte ascesa e sono state tra le vulnerabilità più sfruttate negli ultimi anni (rispetto agli anni passati). Le SSRF si verificano ogni volta che un server o un backend contatta un end-point esterno senza prima verificarlo. Ciò permette di forzare l'applicativo a inviare richieste ad una destinazione inattesa, bypassando eventuali meccanismi di sicurezza come ACL o firewall.
Dato che le moderne applicazioni web forniscono agli utenti finali parecchie funzionalità, scaricare dati da un URL è uno scenario comune. Di conseguenza, l'incidenza di SSRF è in crescita. Inoltre, la gravità di SSRF sta diventando più alta a causa dei servizi cloud e alla complessità crescente delle architetture.
Dato che le moderne applicazioni web forniscono agli utenti finali parecchie funzionalità, scaricare dati da un URL è uno scenario comune. Di conseguenza, l'incidenza di SSRF è in crescita. Inoltre, la gravità di SSRF sta diventando più alta a causa dei servizi cloud e alla complessità crescente delle architetture.
/../../assets/images/favicon.png)
3 Top 10 Mobile Application Security Risks (2016)
Oltre alla OWASP Web Top 10, esiste una classificazione simile, anche se più datata, relativa alle principali vulnerabilità del mondo mobile. Per non sforare con le dimensioni dell'articolo elencheremo dunque di seguito solo le categorie, senza addentrarci nei dettagli di ognuna di loro, ma sentitevi comunque liberi di approfondirle autonomamente tramite la pagina ufficiale della OWASP Mobile Top 10La lista allo stato attuale comprende le seguenti categorie:
- M1: Improper Platform Usage
- M2: Insecure Data Storage
- M3: Insecure Communication
- M4: Insecure Authentication
- M5: Insufficient Cryptography
- M6: Insecure Authorization
- M7: Client Code Quality
- M8: Code Tampering
- M9: Reverse Engineering
- M10: Extraneous Functionality
4 Self training: applicazioni vulnerabili by design
Sul proprio sito ufficiale la OWASP mette a disposizione anche numerose applicazioni (sia web che mobile) vulnerabili "by-design", in modo da permettere a chiunque - studenti o esperti del settore - di potersi esercitare in completa autonomia. Di seguito trovate la lista delle principali applicazioni e la piattaforma per cui sono state ideate:
- Juice Shop (Web)
- vAPI (Web - API)
- UnCrackable Mobile Apps (Android and iOS)
- MSTG Hacking Playground (Android and iOS)
OWASP Vulnerable Web Applications Directory | OWASP Foundation
The OWASP Vulnerable Web Applications Directory Project (VWAD) is a comprehensive and well maintained registry of all known vulnerable web applications currently available for legal security and vulnerability testing of various kinds.
Made with ❤ for Inforge
