Che cos'è la OWASP Top 10?

L’ OWASP Top 10, uno Standard di riferimento che fornisce una classifica e indicazioni per la correzione dei dieci rischi più critici per la sicurezza delle applicazioni web, aiuta gli sviluppatore e gli esperto di sicurezza a comprendere meglio il panorama delle minacce e a orientarsi al suo interno. L’obiettivo finale della OWASP Foundation è contribuire a promuovere una cultura dello sviluppo di software sicuro. Per gli sviluppatori e gli amministratori di applicazioni web, la OWASP Top 10 è un importante riferimento fondamentale per la sicurezza. Fornisce una base su cui costruire app web più sicure 

Che cos'è OWASP?

Open Web Application Security Project, noto anche come OWASP è un’organizzazione no profit con l’obiettivo di migliorare la sicurezza del software. OWASP, oltre a fornire istruzione e formazione, offre una varietà di utili strumenti di sicurezza informatica come:

• Zed Attack Proxy (ZAP)– Un popolare strumento open source di Dynamic Application Security Testing (DAST) per scansioni delle vulnerabilità e test di penetrazione.

• Dependency-Check– Uno strumento di Software Composition Analysis (SCA) che aiuta nel rilevamento delle vulnerabilità nelle dipendenze.

• Dependency-Track– Una piattaforma di analisi dei componenti della supply chain progettata per integrarsi in ambiente CI/CD e identificare i rischi associati ai componenti open source e di terze parti sulla base di una distinta base del software (SBOM).

Quali sono i 10 principali rischi OWASP?

OWASP Top 10 è un elenco dei dieci rischi per la sicurezza più critici per le applicazioni web. È concepito come un documento di sensibilizzazione per sviluppatore e professionisti della sicurezza.  Come le minacce che colpiscono le app web, anche l'elenco stesso cambia di tanto in tanto. Ad esempio, l'elenco del 2013 è stato aggiornato nel 2017 e Open Web Application Security Project ha raccolto dati da marzo a maggio 2020 per l'aggiornamento successivo.

Quindi, quali rischi compongono oggi la OWASP Top 10? Eccoli qui:

1. Injection

Gli attacchi di tipo injection si verificano quando i dati vengono inviati a un interprete tramite un campo di input (ad es. un modulo o l'accesso) in un'app web. Una delle forme più comuni di injection è la SQL injection. Un esempio classico di attacco injection SQL può verificarsi è:

1. Una richiesta di accesso non convalida né sanitizza correttamente gli input del nome utente

2. Un database memorizza nomi utente e password in testo normale (non farlo!) e non dispone di controllo come SQL limite

3. Normalmente, il prompt di accesso dell’app web esegue un’istruzione SQL come

SELECT * FROM utente WHERE name = 'someuser' AND password = 'passwd'

1. Un utente malintenzionato inserisce il nome utente “user OR 1 = 1” e una password qualsiasi.

2. L'istruzione SQL diventa

SELECT * FROM utente WHERE named user' OR 1 = 1 --' AND password = 'passwd'

1. L'utente malintenzionato ottiene l'accesso al contenuto protetto da password

Sebbene oggi molte app impediscano questo semplice caso, è importante ricordare che qualsiasi area di un'app web che accetta parametro di input potrebbe essere soggetta a un attacco injection.

2. Autenticazione compromessa

L'autenticazione non sicura si riferisce all'implementazione non sicura dei metodo di autenticazione e della gestione delle sessioni. Alcuni segnali di autenticazione compromessa includono:

• Consentire attacchi di forza bruta

• Consentire password deboli come “password”

• Memorizzazione di password in testo normale o di password sottoposte ad hashing con una funzione di hash debole o compromessa

• Gestione, rotazione e invalidazione improprie degli ID di sessione e dei token di autenticazione

Per limitare il rischio che un breach comporti la divulgazione delle credenziali, quando un utente crea una password, questa deve essere sia sottoposta a salting sia sottoposta a hashing prima di essere memorizzata. Memorizzare le password in testo normale è l'esempio per eccellenza del mancato rispetto di questa best practice, e persino giganti del cloud pubblico come Google hanno commesso questo errore.

Inoltre, l'autenticazione multifattoriale (MFA) e la limitazione della velocità possono aiutare ad affrontare alcuni dei problemi associati all'autenticazione compromessa, come la vulnerabilità agli attacchi di forza bruta.

 3. Esposizione di dati sensibili

Questa ampia categoria comprende l'esposizione non autorizzata di dati sensibili a riposo o in transito. Spesso le API non crittografano e non trasmettono correttamente dati sensibili come password, numeri di account, dati sanitari e altre informazioni di identificazione personale (PII), il che comporta un rischio di compromissione.

Un attacco man-in-the-middle (MITM) Basic che utilizza SSL striping ci fornisce un esempio di come possano verificarsi breach di dati sensibili:

1. Un hacker compromette un hotspot WiFi

2. L'utente si connette all'hotspot compromesso

3. L'utente tenta di connettersi a https://someinsecuresite.net

4. L’hacker usa un proxy per inoltrare la richiesta dell’utente tramite HTTPS al server

5. L'hacker rimuove la crittografia e restituisce le risposte all'utente tramite HTTP

Ora l’hacker vede tutto ciò che l’utente invia a someinsecuresite.net in testo normale. Il server web somesecuresite.net non ha idea che il traffico sia compromesso, poiché le richiesta ricevute dal server dell’hacker usano HTTPS. L'utente non è consapevole dell'attacco perché sembra che le risposta provengano direttamente da someinsecuresite.net.

Applicare HTTP Strict Transport Security (HSTS) a tutte le pagine, in particolare a quelle che gestiscono dati sensibili, è un modo per ridurre il rischio di esposizione dei dati sensibili. Allo stesso modo, evitare l'uso di una crittografia debole come SSL v3.0 o Transport Layer Security 1.0 contribuisce ad aumentare la sicurezza per il tuo utente. Inoltre, una crittografia forte dei dati a riposo può mitigare le perdite di informazioni di identificazione personale nel caso in cui un database venga compromesso. 

4. Entità esterne XML (XXE)

Extensible Markup Language (XML) è una struttura di dati comune e molte app web possono analizzare input XML. Un attacco XXE è correlato al modo in cui avviene tale analisi. Un hacker invia dati XML che puntano a un'entità esterna.

Un parser XML vulnerabile invierà quindi risposte all'entità esterna, esponendo potenzialmente dati sensibili. Per esempio, supponiamo che un hacker voglia accedere a /path/to/super/secret/file.txt su un server web con un parser XML vulnerabile. L'attacco può presentarsi così:

1. Un hacker invia una richiesta che include questo XML
   <?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE eggs[ <!ENTITY weakparser SYSTEM "file:///percorso/to/super/secret/file.txt"> ]> <movies><filmId>&weakparser;</filmId></movies>

2. Il server risponde con un errore e il contenuto di /path/to/super/secret/file.txt

5. Controllo degli accessi non funzionante

Mentre il numero due della OWASP Top 10 riguarda l'autenticazione, il numero 5 si riferisce a ciò che accade dopo. Il controllo degli accessi si riferisce ai limiti associati a un determinato insieme di privilegi utente.

Esempi specifici di controllo degli accessi non funzionante menzionati da OWASP includono:

• Uso di un URL modificato per aggirare i controlli di accesso. Ad esempio, se userA può accedere alle informazioni dell’account di userB semplicemente cambiando un link da net/myapp/myaccount?user=userA
  a someinsecuresite.net/myapp/myaccount?user=userB

• Escalation dei privilegi. Ad esempio, una vulnerabilità o una configurazione errata che consente a un utente di eseguire azioni di amministratore.

• Accesso non autenticato a pagine privilegiate. Ad esempio, se un utente non autenticato è in grado di accedere a
  net/myapp/super-secret-admin-page
  e visualizzare informazioni privilegiate che normalmente richiedono l'autenticazione.

• Manipolazione dei metadati. Gli esempi includono il replay o la manipolazione dei token di controllo dell'accesso o dei cookie e l'abuso dell'invalidazione dei JSON Web Token.

• Configurazione errata di CORS (Cross-Origin Resource Sharing). Un esempio comune di configurazione errata di CORS è consentire alle richiesta da “localhost” di interagire con applicazioni web di produzione.

6. Configurazione errata della sicurezza

OWASP riporta che la configurazione errata della sicurezza è il problema più comune nel loro elenco. Per impostazione predefinita, molti Pacchetti vengono distribuiti con impostazioni predefinite non sicure e gli sviluppatore web e gli amministratori devono renderli più sicuri. Inoltre, la modifica delle configurazioni per far funzionare una funzione specifica può causare una falla di sicurezza involontaria.

Ad esempio, se per impostazione predefinita consente l'accesso a un pannello di amministrazione con una password predefinita, le credenziali devono essere modificate prima della distribuzione in produzione. Allo stesso modo, i servizi e le porte non necessari devono essere disabilitati o bloccati.

Il punto chiave di questa voce della OWASP Top 10 è: assicurati di configurare in modo sicuro i componenti della tua app E di applicare con attenzione patch e aggiornamenti di sicurezza.

7. Cross-site scripting (XSS)

Cross-site scripting, noto anche come XSS è un problema di sicurezza comune per le app web. Gli attacchi XSS inseriscono script lato client nei contenuti web. Possono consentire agli hacker di rubare dati, dirottare la sessione di un utente o mostrare contenuti modificati in una pagina web. Esistono diversi tipi di attacco XSS, tra cui:

• XSS riflesso – Questa semplice forma di attacco XSS è nota anche come attacco XSS non persistente. In genere utilizza un URL dannoso che punta a un sito legittimo. Nell'attacco, l'URL include caratteri speciali (ad es. caratteri di controllo HTML) che le pagine vulnerabili poi eseguono.

• XSS memorizzato – Questi attacchi sono indicati anche come XSS memorizzato. Nel caso di XSS memorizzato, i dati dannosi forniti da un hacker vengono salvati lato server. Il risultato è che il contenuto compromesso viene visualizzato a tutti gli utente che visitano la pagina.

• Cross-site scripting (XSS) basato su Document Object Model (DOM) – gli attacchi XSS basati su DOM sono unici in quanto l'exploit generalmente non tocca mai il server. Il codice front end come JavaScript viene sfruttato per eseguire script dannosi.

8. Deserializzazione non sicura

Serialization is the process used to convert data objects into a specific format for purposes such as streaming or data storage. Serialized data can be binary or plaintext data (like JSON or XML). Deserialization is the process of reversing serialization and converting the serialized data back to a data object.

Il processo di serializzazione/deserializzazione può diventare un problema quando sono coinvolte fonti non attendibili di dati serializzati. Un hacker può includere Operazioni specifiche nei dati serializzati e, se l'attacco ha successo, il server le eseguirà nel processo di deserializzazione. Ciò significa che la deserializzazione non sicura può essere usata per attacchi che vanno da DDoS all'escalation dei privilegi.

Open Web Application Security Project fornisce un buon esempio di deserializzazione non sicura utilizzando come esempio un'applicazione forum vulnerabile basata su PHP. Supponiamo che l'app utilizzi un super cookie che memorizza un ID utente, il ruolo dell'utente e le informazioni hash della password.
Un hacker potrebbe modificare il cookie per concedersi privilegi elevati, in questo modo:

Prima:

a:1:{s:1:"MalicousUser";i:1;s:2:"guest"; i:1;s:1:" fe7pmk43i1wstgqvsyask27g44yxn7qhl6zgkr7ivho1e6lv903xc9sbiq4b6mtx";}

Dopo:

a:1:{s:1:"SuperAdmin";i:1;s:2:"admin"; i:1;s:1:" fe7pmk43i1wstgqvsyask27g44yxn7qhl6zgkr7ivho1e6lv903xc9sbiq4b6mtx";}

9. Utilizzo di componenti con vulnerabilità note

Questo rischio è esattamente ciò che il nome suggerisce: l'uso di componenti vulnerabili all'interno di un'app web. Le moderne applicazioni web dipendono da una varietà di framework, libreria e modulo. Se uno qualsiasi di questi componenti sottostanti presenta vulnerabilità di sicurezza, l'intera app può essere messa a rischio. Come per il numero sei della OWASP Top 10, applicare patch e aggiornamenti di sicurezza può fare molto anche in questo caso.

10. Logging e monitoraggio insufficienti

Il rapido rilevamento di minacce tentate o breach confermati è una parte importante della prevenzione o mitigazione dei danni. Le attività dannose spesso hanno uno schema unico e un monitoraggio efficace può aiutare a rilevarle rapidamente. In molti casi, i breach non rilevati portano a danni più estesi, motivo per cui questo rischio è entrato nell'elenco. Infatti, secondo Open Web Application Security Project, la maggior parte degli studi suggerisce che il tempo necessario per rilevare una data breach supera i 200 giorni.

Alcuni esempi comuni di logging e monitoraggio insufficienti includono:

• Non fare logging di eventi di alto valore come accessi e tentativi di accesso non riusciti

• Nessun messaggio o messaggi di errore ambigui e messaggi di Log per eventi di livello warning o superiore

• Memorizzazione dei Log solo localmente sul server

• Le scansioni di sicurezza non attivano notifiche o Avvisi

• Nessun avviso in tempo reale per gli attacchi

Come un web application firewall può aiutare ad affrontare la OWASP Top 10

Non esiste una soluzione miracolosa unica per mantenere al sicuro la tua applicazione web dalle minacce dell'OWASP Top 10. Dovrai assicurarti che la sicurezza sia presa in considerazione nel codice, nella configurazione dell'infrastruttura e nei componenti di terze parti che utilizzi.

Detto questo, un Firewall per applicazioni web può semplificare notevolmente il lavoro necessario per proteggere la tua applicazione web. La definizione di web application firewall di OWASP evidenzia i casi d'uso comuni per mitigare attacchi come XSS e SQL injection.

Quindi, in che modo esattamente un web application firewall può aiutare in questi casi? I WAF configurati correttamente possono rilevare e bloccare richieste potenzialmente dannose. Combinando rilevamenti predefiniti e funzionalità personalizzabili in soluzioni come il Next-Gen WAF di Fastly e sfruttando le capacità della nostra piattaforma edge cloud, puoi ottenere una solida copertura dell’OWASP Top 10. 

Per indicazioni più dettagliate ed esempi reali su come risolvere le minacce OWASP con Fastly, puoi consultare il nostro whitepaper.