OWASP: quali sono le minacce per le applicazioni web?

La Open Web Application Security Project (OWASP) è una fondazione senza scopo di lucro che incentra le sue attività sulla produzione di risorse, articoli e materiale relativo a problematiche collegate con la sicurezza informatica. Non affiliata con alcuna società, OWASP può contare sul supporto di una comunità di collaboratori a livello mondiale.
A distanza di tre anni (le precedenti indagini risalivano al 2004, al 2007 ed al 2010), OWASP ha appena aggiornato la classifica relative alle minacce per la sicurezza ritenute maggiormente critiche.

La “OWASP Top 10 2013” (prelevabile cliccando qui; file in formato PDF) si propone come un valido aiuto per professionisti e realtà aziendali. L’obiettivo è quello di diffondere una maggiore consapevolezza sulle minacce informatiche e favorirne una più corretta gestione.

Di seguito le problematiche che OWASP menziona in ordine di importanza: vediamone in breve il significato.

1° Injection Flaws (in 1° posizione nel 2010)
Si chiama “SQL injection” una particolare pratica di hacking che mira a colpire applicazioni web che si appoggiano a DBMS (ad esempio, MySQL, SQL Server, Oracle, Access e così via) per la memorizzazione e la gestione di dati. L’attacco si concretizza quando l’aggressore riesce ad inviare, semplicemente usando il browser, una query SQL arbitraria all’applicazione web.
Quando i dati inviati in input non vengono opportunamente filtrati, l’interrogazione SQL ricevuta in ingresso dalla pagina web, potrebbe essere “agganciata” alla query effettuata a livello server dall’applicazione web. I risultati possono essere drammatici: l’aggressore, nel caso in cui l’attacco dovesse andare a buon fine, può essere in grado di alterare dati memorizzati nel database, aggiungere informazioni maligne nelle pagine web dinamiche generate a partire dal contenuto della base dati, modificare username e password.

2° Broken Authentication and Session Management (in 3° posizione nel 2010)
Le credenziali di autenticazione e i “session token” sono spesso non adeguatamente difesi.
Un “session token” è un identificatore univoco, solitamente prodotto nella forma di un valore di hash, che viene generato ed inviato dal server al client in modo tale da stabilire la corrente sessione di lavoro. Il client memorizza ed invia il token come un cookie HTTP trasmettendolo come parametro nelle query GET e POST.
Un aggressore può sfruttare le “lacune” nella gestione di questi dati per modificare password, chiavi od assumere identità altrui.

3° Cross Site Scripting (XSS) (in 2° posizione nel 2010)
Una vulnerabilità XSS si presenta nel momento in cui un’applicazione prende in carico i dati ricevuti in ingresso reinviandoli poi al browser web senza operare una validazione dell’input o senza codificarlo in alcun modo.
Malintenzionati possono sfruttare falle XSS per eseguire script nocivi attraverso il browser web dell’utente, sottraendo dati di autenticazione, invocando il download di malware, modificando porzioni del sito web visitato.

4° Insecure Direct Object Reference (in 4° posizione anche nel 2010)
Il problema di sicurezza si verifica nel momento in cui lo sviluppatore espone in chiaro dei riferimenti ad oggetti-chiave come file, directory, database, chiavi. L’aggressore potrebbe manipolare questi riferimenti per accedere ad altri oggetti senza alcuna autorizzazione.

5° Security Misconfiguration (in 6° posizione nel 2010)
Una configurazione lato server sicura è sempre la chiave di volta per non avere problemi di sicurezza. I software installati debbono essere sempre mantenuti aggiornati e le impostazioni di applicazioni, framework, software server, database server e sistemi operativi vanno sempre revisionate per accertarsi della loro adeguatezza.

6° Sensitive date exposure (non in classifica nel 2010)
I tecnici di OWASP fanno riferimento alla scarsa protezione dei dati sensibili conferiti dagli utenti che viene offerta da molte applicazioni web. Il rischio che si corre, in questo caso, è che un aggressore si impadronisca di informazioni sulle carte di credito e sulle credenziali di autenticazione appartenenti ad altri utenti.

7° Missing Function Level Access Control (non in classifica nel 2010)
Un’applicazione web generalmente effettua il controllo delle credenziali d’accesso di un utente e visualizza, di conseguenza, gli strumenti che possono essere utilizzati con quello specifico account. La disponibilità dei permessi per l’utilizzo di ogni specifica funzione dev’essere controllata anche nel momento in cui l’utente richiede l’accesso alla funzione stessa.

8° Cross Site Request Forgery (CSRF) (in 5° posizione nel 2010)

Si tratta di un attacco che si concretizza inviando ad una applicazione web delle richieste sfruttando le autorizzazioni di un utente “trusted”, ad esempio una persona che abbia effettuato il login su un determinato sito web.
Supponiamo che l’utente Bob sia loggato su un sito web di una banca e che, non effettuando il login, egli acceda – ad esempio – ad una pagina web dove il malintenzionato Mallory ha pubblicato un messaggio. Il messaggio preparato da Mallory contiene, ad esempio, una tag html IMG che fa riferimento ad uno script residente sul server della banca di Bob.
Visitando la pagina “dannosa”, Bob potrebbe quindi inconsapevolmente dare il via ad un’operazione che lui non ha richiesto.
Ecco perché è sempre consigliabile effettuare il logout da qualsiasi servizio online si stia utilizzando.
Un esempio su tutti? La vulnerabilità CSRF scoperta dal ricercatore Petko D. Petkov a fine 2007 all’interno del servizio Google GMail.
In alcune schermate dimostrative pubblicate sul sito Gnucitizen.org, Petkov illustrò una possibile forma di attacco: “nell’esempio, l’aggressore prepara un filtro aggiuntivo che permette di estrarre le e-mail con allegato e le inoltra ad un altro indirizzo e-mail di sua scelta”, dichiarò il ricercatore. Un attacco potrebbe innescarsi nel momento in cui l’utente visiti un sito web maligno, opportunamente sviluppato per far leva sulla lacuna di sicurezza, rimanendo loggato al servizio GMail. Il sito maligno avvierà poi quello che Petkov definisce “multipart/form-date POST“, un comando che può essere impiegato per caricare file, inviandolo all’application programming interface di GMail. L’aggressore avrà la possibilità di “iniettare” un filtro personalizzato a quelli usati da GMail.
La vittima dell’attacco sarà costantemente “sotto scacco” (la sua posta elettronica, nell’esempio, continuerà ad essere inoltrata a terzi, a sua insaputa e senza la sua autorizzazione) finché il filtro “maligno” sarà presente nella scheda Impostazioni, Filtri del servizio GMail. Google, da parte sua, comunicò poi di aver risolto il problema.

9° Using Components with Known Vulnerabilities (non in classifica nel 2010)
L’utilizzo di applicazioni e componenti che presentano vulnerabilità di sicurezza è sempre da evitare. Un aggressore può infatti sfruttarle per acquisire privilegi più elevati o per eseguire codice in modalità remota.

10° Unvalidated Redirects and Forwards (al decimo posto anche nel 2010)
Le applicazioni web reindirizzano frequentemente il browser verso altre pagine od altri siti web. Talvolta il dato relativo alla destinazione non viene sottoposto ad un’adeguata attività di validazione. In questo modo, può capitare che gli aggressori siano in grado di reindirizzare le vittime verso siti contenenti malware o pagine utilizzate per attacchi phishing.