La sicurezza delle applicazioni Web secondo l'Open Web Application Security Project

Con la progressiva diffusione di architetture distribuite, aperte e flessibili, garantire la sicurezza e l'integrità dei sistemi informativi aziendali è divenuto un compito complesso; se da un lato le applicazioni web hanno portato evidenti benefici in termini di fruibilità per l'utente, dall'altro hanno sicuramente introdotto un nuovo elemento debole ai sistemi. Il requisito della sicurezza nelle applicazioni web rimane, ad oggi, uno dei principali problemi che affligge questa tecnologia; basta scorrere le security advisory pubblicate su, ad esempio, SecurityFocus per accorgersi della gravità del fenomeno.

Sul totale delle vulnerabilità segnalate, una grossa percentuale è da attribuire a software sviluppati con tecnologie web. Dall'esigenza di contrastare le cause dei software insicuri su internet nasce OWASP (Open Web Application Security Project): un progetto open source con l'obiettivo primario di trovare e combattere le falle che affliggono le applicazioni web. Attraverso il lavoro svolto da centinaia di volontari sparsi in tutto il mondo si vuole studiare il fenomeno e produrre documentazione tecnica e software per cercare di risolvere il problema; anche l'Italia ha un capitolato nazionale e chiunque interessato è invitato a partecipare alle discussioni nella mailing list, oltre alle altre attività svolte dal gruppo locale.

L'importanza di avere un punto di discussione e confronto rispetto a questi temi è fondamentale per poter avere una visione oggettiva della situazione: errori di ingegnerizzazione del software, semplici sviste implementative oltre che una mancanza di consapevolezza sono fattori che devono essere considerati quando andiamo a pubblicare un'applicazione che è esposta a milioni di utenti.

È ormai opinione diffusa che le applicazioni web siano, per loro natura, soggette alla presenza di vulnerabilità: il contesto applicativo entro cui operano e le tecnologie utilizzate giocano a sfavore per garantire la confidenzialità e l'integrità dei dati.

L'ambiente di fruizione è intrinsecamente aperto alla comunicazione remota e spesso gli utenti vi accedono in maniera non autenticata; le informazioni trattate possono essere di rilevanza cruciale per il business aziendale (pensiamo alle classiche interfacce web per la gestione del database centrale); a questo aggiungiamo che il protocollo HTTP è stato sviluppato in un'epoca in cui Internet era molto diversa dal luogo che è oggi, in cui per esempio, il concetto di persistenza non esisteva. 

Se la gravità del fenomeno è ormai evidente, quello che non c'è ancora è una soluzione. Citando una frase del fondatore di OWASP, Mark Curphey: ­«Non esiste una bacchetta magica per la risoluzione dei problemi di sicurezza relativi alle applicazioni web. Quello che serve realmente è un ottimo team, molta esperienza, molto training e l'utilizzo di soluzioni allo stato dell'arte».

Consapevolezza, conoscenza e rispetto delle "best practices" sono gli unici elementi che ogni buon sviluppatore possiede per realizzare delle applicazioni sicure in un ambiente che è ben lontano dall'esserlo.

OWASP Top Ten, le dieci vulnerabilità più critiche.

Nella definizione di standard di sicurezza, OWASP propone una classifica (OWASP Top Ten) in cui vengono enumerate le vulnerabilità che affliggono i software su internet. In questo documento, in costante evoluzione, sono definiti in maniera ordinata le criticità delle applicazioni, fornendo un ottimo punto di partenza per la preparazione di checklist.

Se in un primo momento si pensa che sia l'ennesima pubblicazione di problematiche note da anni, ci si accorge ben presto di quanto sia indispensabile la definizione formale delle vulnerabilità; definire una lista comune di problematiche è il primo passo per discutere ed affrontare il problema a livello di comunità, come avviene per le questioni legate al networking con la lista SANS.

Iniziamo quindi la nostra panoramica sulle dieci vulnerabilità più critiche, partendo dal problema più diffuso ed in un certo senso più pericoloso.

A1 - Unvalidated Input

Rientrano sotto questa categoria tutti i problemi legati alla mancanza di validazione dell'input o alla validazione parziale. L'interazione dell'utente con l'applicazione avviene attraverso uno scambio di messaggi, secondo il protocollo HTTP, che può essere semplicemente descritto attraverso lo schema sottostante:

Un utente, e quindi anche un potenziale aggressore, può modificare in parte o completamente la richiesta inoltrata verso il Server Web, plasmando a piacere il contenuto di tali parametri. La possibilità di editare le variabili nell'header HTTP, il valore dei campi ritornati da un form, e così via, apre l'enorme problematica legata alla validazione dei parametri che l'applicazione, sul server, potrà accettare.

Nel caso in cui il controllo sui valori in ingresso non sia ben implementato, correrò il rischio di esporre la mia applicazione ad una serie di attacchi noti che vanno dal classico SQL injection, al cross site scripting (OWASP-A4), buffer overflow, format string,  e così via.

A titolo di esempio illustriamo una vulnerabilità presente in una vecchia versione del noto applicativo Squirrel Mail. Squirrel è una classica Webmail sviluppata in php che, attraverso un plugin, permette l'utilizzo di un database MySQL per la gestione dei contatti. In particolare, per quello che interessa la nostra analisi, sul database è presente la seguente tabella:

Nella versione 1.15.2.1 di tale software, all'interno della pagina: /squirrelmail/squirrelmail/functions/abook_database.php è codificata la seguente query SQL:

In nessun punto precedente del codice viene effettuato un controllo sul contenuto delle variabili e poichè tale valore è modificabile dall'utente, il mancato controllo di validazione dell'input rappresenta la giusta collocazione per un attacco di SQL injection. Per esempio, se la variabile $alias contenesse la seguente stringa:

Tale segmento di codice genererebbe la seguente istruzione SQL:

Supponendo che non ci sia nessun utente con il campo nickname vuoto, la prima SELECT non restituirà risultati mentre la seconda, poichè costruita con una clausola WHERE incondizionata, ritornerà tutte le tuple contenute nel database. L'utilizzo del comando SQL di aliasing (AS) permetterebbe poi di bypassare gli eventuali problemi di visualizzazione dei risultati della query. Una semplice risoluzione di tale problema (presente nella versione successiva, la 1.15.2.2) utilizza un'istruzione di verifica quoteString, presente nella libreria PEAR MDB2, che effettua l'escape del carattere apice. Una soluzione semplice ad un problema concettualmente semplice, ma spesso difficile da  individuare senza una piena consapevolezza.

Continuando la nostra descrizione sulle problematiche di validazione dell'input è importante ricordare come non ci si debba mai affidare a soluzioni di verifica dei parametri con controlli "lato client" (per esempio tramite JavaScript) in quanto il codice stesso è manipolabile dall'aggressore che potrebbe bypassare il controllo, semplicemente salvando in locale la pagina e modificando il sorgente.

Il modo migliore per proteggersi da questo tipo di attacchi è quindi quello di assicurarsi che i parametri in input siano "sanitizzati" ('resi sicuri') prima che siano effettivamente utilizzati all'interno dell'applicazione. Le migliori soluzioni si basano su quelle che vengono chiamate whitelist ovvero delle liste in cui specificare tutto quello che l'applicazione può accettare; questa tecnica differisce dalla duale blacklist, in cui invece viene specificato tutto quello che non deve essere accettato. Per valori "non ammissibili" intendiamo degli input che possono generare errori anche a livello funzionale oltre che strettamente legati alla sicurezza.

La prima soluzione è sicuramente preferibile in quanto spesso non è possibile definire in maniera precisa cosa scartare; a questo si aggiunge la naturale evoluzione del software che subisce periodicamente modifiche e reingegnerizzazioni. Per implementare il meccanismo di whitelist appena definito, si ricorre spesso all'utilizzo di framework appositi, librerie esterne al programma o eventualmente ad application firewall che lavorano tramite set di regole.

A2 - Broken Access Control

All'interno di applicazioni web multiutente sono spesso presenti dei meccanismi di autorizzazione denominati controlli d'accesso. La corretta implementazione consente di associare ad ogni tipologia d'utenza un corrispettivo gruppo di appartenenza con ruoli, credenziali e privilegi diversi. La gestione delle autorizzazioni deve iniziare dalla formalizzazione di alcune policy che regolano che cosa è lecito per ogni diversa classe d'utenza; già durante la fase di design è importante considerare attentamente ogni singolo aspetto.

Nella fase successiva, quella dell'implementazione, è bene evitare alcuni classici errori:

• Errati permessi dei file:non permettere la visualizzazione dei file localmente presenti sul web server (file di configurazione, script, file di default o backup vari); attenzione a marcare i file come eseguibili.
• Forced browsing per superare una restrizione d'accesso: molte applicazioni prevedono dei controlli prima di accedere ad un indirizzo profondamente nidificato all'interno del sito. È necessario evitare che un utente possa saltare tali controlli forzando la navigazione (es: non fidarsi della variabile HTTP_REFERER).
• Insecure ID: non bisogna affidarsi alla segretezza degli ID usati comunemente per distinguere gli utenti, i gruppi di appartenenza e quindi i relativi privilegi. Se un aggressore riuscisse a leggere tali valori e capire la logica dell'assegnazione (es: il valore "0" per l'utente root) potrebbe generare delle richieste HTTP modificate, scardinando il meccanismo di controllo implementato.
• Client Side Caching: le pagine salvate in cache dai moderni browser sono un pericolo costante per la riservatezza dei dati di quelle persone che navigano attraverso postazioni pubbliche (scuole, internet point, etc.). Lo sviluppatore dovrebbe adottare tutte le soluzioni tecniche per evitare il caching delle pagine contenenti informazioni sensibili.

Concludiamo questa prima parte di presentazione della nomenclatura OWASP Top Ten, invitando il lettore interessato a proseguire nella lettura della seconda parte dell'articolo, in cui illustreremo le altre vulnerabilità critiche individuate dagli esperti.

Dopo aver visto, nelle prime pagine dell'articolo, le prime due grandi famiglie di vulnerabilità critiche (gli input non validati e i controlli di accesso non sicuri), continuiamo ora con la Top Ten definita dagli esperti di OWASP.

A3 - Broken Authentication e Session Management

Nelle moderne applicazioni web, la gestione dell'autenticazione è uno dei primi meccanismi messo in atto per discriminare un utente riconosciuto da uno estraneo. Solitamente l'utente si presenta (fase di identificazione) inviando username ed una password che attesta la sua conoscenza del "segreto condiviso" (fase di autenticazione).

A seguito di questa procedura, per la natura stateless del protocollo HTTP, è necessario tener traccia delle operazioni compiute durante la navigazione dal singolo navigatore; pensiamo ad una tipica applicazione commerciale, in cui è necessario mantenere un carrello virtuale con i prodotti acquistati dall'utente. Per dotare le applicazioni web di questa funzionalità, negli anni sono state sviluppate numerose tecniche ma, ad oggi, la più comune è quella basata su token di sessione (il metodo è stato descritto per PHP in un articolo di HTML.it).

In pratica, nella fase che segue l'autenticazione, il server associa al client un ID di sessione che distinguerà univocamente un utente da un altro; ogni qualvolta il browser dell'utente  effettua una richiesta verso l'applicazione invia anche tale identificativo, permettendo di tracciare le varie operazioni compiute nel tempo. Sul lato client tale informazione è spesso memorizzata all'interno dei cookie. Nella figura successiva è schematizzato il classico meccanismo dei session token.

 

Il meccanismo di autenticazione e la gestione delle sessioni sono elementi importanti per assicurare dei requisiti minimi di sicurezza nelle applicazioni web. L'utilizzo di password considerate "deboli", ovvero composte da pochi caratteri (solamente alfabetici), che compongono parole d'uso comune nella lingua considerata, è una pratica sconsigliata in quanto rende possibile un attacco a forza bruta basato su dizionari.

Per le stesse ragioni è consigliabile infatti adottare delle policy di cambio password che non permettano l'inserimento di parole chiave già utilizzate in passato, oltre ad un controllo capillare dei tentativi di login.

Per quanto riguarda la gestione delle sessioni è fondamentale proteggere l'ID di sessione utilizzando un canale di trasmissione sicuro (SSL, per esempio) in maniera da ridurre il rischio di intercettazione; è altresì importante utilizzare identificativi che siano difficili da generare e composti, in maniera casuale, facendo uso di complicate catene di numeri e caratteri. Se i token di sessione non vengono adeguatamente protetti, un aggressore potrebbe dirottare una sessione attiva e assumere il ruolo di un malcapitato utente.

Analizzando la categoria successiva di vulnerabilità, scopriremo che adottare tutte le precauzioni illustrate non scongiura completamente dal rischio di essere vittime di un attacco di session hijacking.

A4 - Cross Site Scripting (XSS)

Il Cross Site Scripting - spesso abbreviato con XSS e a cui abbiamo dedicato un articolo tecnico alcuni mesi fa - è una vulnerabilità che consente ad eventuali aggressori di inserire del codice arbitrario all'interno delle applicazioni web, così da modificarne il comportamento per perseguire i propri fini illeciti. Il codice inviato, spesso sotto forma di script (JavaScript, VBScript e così via), verrà eseguito senza alcun controllo dal browser dell'utente poichè inoltrato da una sorgente ritenuta sicura: il server web da cui proviene la pagina.

Gli attacchi XSS possono essere divisi in due grandi categorie: attacchi stored  e attacchi reflected. I primi si verificano quando il codice nocivo è conservato dall'applicazione stessa e viene presentato all'utente ogni qualvolta si accede ad una specifica pagina (es: un messaggio, all'interno di un forum, che contiene JavaScript). Nella seconda categoria rientrano quegli attacchi che utilizzano altri canali di comunicazione (es: email, messaggi attraverso IM client e così via) per trasmettere un link "modificato", il quale rindirizzerà il codice verso l'utente.

Le vulnerabilità XSS possono essere sfruttare dall'aggressore in molti modi; vediamo qualche possibile scenario, così da capirne la pericolosità:

• Session Hijacking: è sicuramente l'utilizzo illecito più comune; in questo modo un aggressore può rubare le credenziali dell'utente e utilizzare l'applicazione con i privilegi di quest'ultimo. Solitamente questo attacco è attuato inviando un semplice script all'interno del sito vulnerabile e forzando l'utente a visitare la pagina che contiene le istruzioni dannose; spesso per convincere la vittima si utilizzano tecniche di social engineering. Ricordiamo che il codice inserito dall'aggressore viene eseguito dal browser dell'utente come una qualsiasi altra informazione proveniente dal sito visitato: la vittima non si accorgerà di nulla se le istruzioni inserite copiano il token di sessione, presente all'interno dei cookie, e lo inviano verso un sito esterno. Se l'applicazione non controlla la sessione attraverso altri meccanismi, l'aggressore ha quindi tutte le informazioni che servono per impersonificare l'utente.

  Un attacco leggermente diverso, ma con simili risultati, è quello denominato session fixation: in questo caso l'aggressore richiede un token di sessione valido attraverso una normale richiesta e lo inoltra verso la vittima, creando una "trap session". Alcune applicazioni permettono la definizione di session ID attraverso un'esplicita richiesta presente nell'URL (es: login.php?PHPSESSID=1234), rendendo possibile la condivisione del medesimo token di sessione tra utente ed aggressore che può quindi controllare la navigazione.

• User Tracking: un altro uso di XSS è quello relativo all'ottenimento di informazioni riguardo la tipologia di visite e di visitatori in un sito web, per poi poter iniziare attività di spamming.

• Browser/User exploitation: l'invio di codice dannoso può rendere difficile la navigazione, intervenendo sulle modalità di interazione tra sito ed utente. L'aggressore potrebbe forzare l'apertura di alert box o il reload delle pagine, obbligando l'utente ad interrompere la visita al sito oppure forzando eventuali percorsi di navigazione.

• Credentialed Misinformation/Information Dissemination: dal momento che Internet sta assumendo un ruolo importante come mezzo propagandistico, questo ultimo attacco XSS non deve essere trascurato. Attraverso l'invio di script, in esecuzione sul browser, è possibile modificare attivamente il contenuto di un sito e la modalità di presentazione. Le notizie ed i contenuti riportati nelle varie pagine web vulnerabili possono essere cambiati a proprio piacimento, creando disinformazione. Scenari possibili vanno dalle modifiche di alcune notizie all'interno dei giornali online, al cambio di valori nel sito della borsa sino all'inserimento di pubblicità in siti molto frequentati.

L'eventualità che un sito contenga una vulnerabilità di questo tipo è estremamente elevata poichè spesso non è semplice filtrare l'input dell'utente: esistono innumerevoli modi per inserire del codice JavaScript all'interno di pagine HTML, molti standard e differenti meccanismi di invio dei dati. Non dobbiamo inoltre dimenticare che parlando di scripting lato client non esiste solo JavaScript ma anche ActiveX(OLE), VBScript, Flash, etc.

Per completezza è poi giusto ricordare che vulnerabilità di XSS sono state riscontrate in alcuni software come Apache Tomcat, Microsoft IIS, Lotus Domino e IBM WebSphere in cui nei messaggi di errore, se non opportunamente filtrati, è possibile inserire del codice.

Ora che conosciamo i rischi della vulnerabilità, vediamo in maniera pratica come è possibile sfruttarla attraverso un esempio reale presente in una vecchia versione di Squirrel Mail.

All'interno della pagina event_delete.php sono presenti le seguenti istruzioni:

In questa parte dello script, le variabili rappresentanti il giorno, mese e anno vengono prelevate da una precedente richiesta, per comporre una nuova pagina HTML. Poichè non è stato introdotto alcun controllo sul contenuto delle variabili, queste potranno essere usate per inserire del codice nocivo da far eseguire direttamente all'utente stesso. Inserendo quindi una stringa del tipo:

e convincendo l'utente ad aprire tale URL (per esempio tramite una email o una segnalazione su forum pubblici) è possibile eseguire comandi sul client. Come detto, questa situazione è l'ideale per attacchi di session hijacking in cui poter prelevare cookie ed altre informazioni sensibili dall'utente stesso. La pagina HTML di risposta alla richiesta HTTP dell'utente è infatti:

il parametro year, ora riempito con la funzione myCode(), è il mezzo attraverso il quale eseguire del codice arbitrario. Analizzando le nuove versioni dell'applicativo, ci si rende conto di quanto questo problema sia risolvibile attraverso l'utilizzo di parametri unicamente numerici ed una serie di funzioni di controllo (es: is_numeric($_GET['year']) ).

La soluzione adottata dagli sviluppatori di Squirrel Mail dimostra come un'attenta validazione sia l'unica vera soluzione. Come consigliato dagli esperti di OWASP è bene definire una policy di sicurezza che specifichi le tipologie di dati da trattare, filtrare l'input e anche l'output in maniera da inibire le falle provocate da XSS; questo ultimo aspetto è facilmente realizzabile convertendo i caratteri "pericolosi" negli equivalenti HTML entity encoding (es:"<" diventa <).

Per l'utente web, il metodo più sicuro per proteggersi da attacchi di Cross Site Scripting è quello di disabilitare l'esecuzione di codice lato client; nel browser Firefox 1.5.0.4 è possibile farlo deselezionando, con un semplice click, la voce Enable Java/JavaScript all'interno del pannello Preferences / Content.

Ovviamente questo accorgimento limita la dinamicità e la ricchezza delle moderne applicazioni, che non possono essere sfruttate pienamente; durante operazioni importanti e riservate potrebbe però essere l'unica soluzione efficace. Un'ulteriore raccomandazione è quella di fare molta attenzione a link contenuti all'interno di email anonime o in pagine web poco conosciute.

Terminiamo qui il secondo approfondimento dedicato alle vulnerabilità nelle applicazioni web, rinnovando l'appuntamento alla terza e ultima parte in cui illustreremo le ultime categorie di vulnerabilità segnalate nella OWASP Top Ten.

Terminiamo, con questo appuntamento, la presentazione della OWASP Top Ten: un
elenco ragionato delle vulnerabilità critiche nelle applicazioni web. Nelle
prime due sezioni abbiamo visto le prime quattro importanti vulnerabilità da
tenere d'occhio (input
non validati,

controlli di accesso non sicuri,
autenticazioni e
Cross Site Scripting). In questo prenderemo in esame le restanti sei.

A5 – Buffer Overflow

Il
Buffer Overflow è un attacco che sfrutta una validazione errata
dell’input, in cui non si controlla la lunghezza della sequenza di dati ricevuti
dall’applicazione. Un utente, per errore o maliziosamente, può modificare la
parte di codice in esecuzione nello stack andando a cambiare il flusso di
esecuzione del software.

Tecnicamente esistono diverse strategie - stack overflow, heap overflow,
format string - che possono però essere ricondotte ad un’unica grande famiglia
di vulnerabilità in cui l’aggressore può riuscire ad eseguire comandi arbitrari.
Nel caso delle applicazioni online è possibile riscontrare tale vulnerabilità
sia nel web server stesso che all’interno di librerie custom utilizzate dalla
web application.

Questa vulnerabilità è al contempo una delle più difficili da riscontrare e
da sfruttare: un aggressore, senza il codice sorgente, difficilmente riuscirà a
creare un exploit per inviare comandi remoti al sistema; è molto più probabile
che riesca solamente a bloccare il servizio, interrompendo in ogni caso la
normale esecuzione del software.

È opportuno ricordare che, con l’avvento delle tecnologie java (JSP) e gli
altri linguaggi interpretati, tale problematica sta lentamente diminuendo e
lasciando posto nella classifica a nuove sfide per garantire la sicurezza.

A6 – Injection Flaw

Se risulta possibile, inserendo da remoto del codice custom, effettuare
operazioni che normalmente non sono consentite, siamo in presenza di un
Injection Flaw.

Molto spesso le applicazioni web fanno uso di programmi esterni o di system
call per eseguire i compiti per cui sono state sviluppate: se un aggressore
riesce a modificare parte di una chiamata a tali componenti del sistema
operativo potrà veicolare ed eseguire altre istruzioni.

Un esempio tipico è quello di un parametro scelto dall’utente ed utilizzato
all’interno di una system call; un utente potrebbe inserire, alla fine del
parametro, dei comandi in aggiunta a quelli hardcoded già presenti all’interno
dell’applicazione (esempio "<nome_file>; rm –rf /home/").
In casi eclatanti è possibile veicolare dei codici completi in PHP, Perl o altri
linguaggi, per poi eseguire direttamente il codice sul server.

Lo sviluppatore può ridurre il rischio di Injection validando attentamente
tutti i parametri in ingresso, oltre che limitando l’uso di chiamate esterne.
Dal punto di vista del sistemista o del semplice utilizzatore di software terze
parti, è consigliabile controllare periodicamente i permessi ed i privilegi
degli utenti con cui eseguiamo tali applicazioni (esempio: il web server non
deve MAI essere eseguito come utente root).

A7 - Improper Error Handling

Questa classe di vulnerabilità è un esempio concreto di come bastano piccoli
accorgimenti per ridurre notevolmente il rischio di un’aggressione informatica.

Arrivare a rubare dati dal server o eseguire codice su di esso implica una
piena conoscenza del sistema che bisogna aggredire e dei meccanismi di sicurezza
da aggirare; all’aggressore servono informazioni sui servizi presenti, sulle
loro versioni e configurazioni oltre che sulla struttura delle directory. Una
gestione non corretta degli errori può rivelare in maniera diretta tali
informazioni, trasformando un errore apparentemente innocuo in un messaggio
utilissimo per scopi illeciti. Per accorgersi di quanto può essere rischioso,
pensiamo ai seguenti messaggi, nei panni di un cyber criminale:

Il messaggio precedente rivela alcune preziose informazioni: il tipo di
piattaforma (Microsoft Windows), il tipo di database (SQL Server tramite ODBC)
ed il particolare che la query SQL, molto probabilmente introdotta dall’utente,
non combacia in numero con i parametri specificati nell’istruzione presente nel
codice. A questo punto conosciamo il nostro target e possiamo scegliere
opportune funzioni del DBMS per costruire la nostra SQL Injection. Con alta
probabilità il nostro attacco andrà a buon fine.

Vediamo un altro esempio:

In questo caso nessuna informazione tecnica ma, un dato chiaro, che l’utente
admin esiste. All’interno di applicazioni come questa è possibile enumerare
tutti gli utenti, provando poi a forzare eventuali password deboli.

Per difendersi, il principio base è quello di non fornire mai messaggi
dettagliati ma, al contrario, errori generici una volta che la nostra
applicazione è online. L’utente non deve leggere niente di più di quello che gli
serve per comprendere lo stato della sua richiesta.
Una buona prassi è quella di loggare alcune classi di errore – solitamente le
più critiche – per semplificare l’individuazione di errori di implementazione e
smascherare eventuali tentativi di attacco.

A8 – Insecure Storage

Nelle applicazioni web c’è spesso la necessità di salvare grosse quantità di
dati: pensiamo alle informazioni di login, al profilo degli utenti e ai dati più
riservati che vengono trattati durante gli acquisti online. La classe di
vulnerabilità definita Insecure Storage considera infatti tutte quelle
situazioni in cui i dati non sono conservati in maniera adeguata.

Per fornire un ulteriore livello di sicurezza alla nostra applicazione è
spesso consigliabile l’utilizzo di algoritmi di cifratura o hashing, in maniera
da evitare che un utente che riesca ad accedere al database – per esempio
tramite
SQL Injection - riesca anche a leggere i dati.
Durante la fase di login è bene effettuare il confronto tra un hash della
password immessa dall’utente e l’hash precedentemente salvato sul sistema,
invece che un semplice confronto tra stringhe in chiaro. Considerando che nei
moderni linguaggi sono disponibili moltissimi degli algoritmi di hashing noti
(MD5, SHA-1, ecc), l’implementazione della fase di login, come quella descritta,
non complica ulteriormente il lavoro dello sviluppatore.

Anche quando vogliamo cifrare i dati attraverso algoritmi simmetrici è buona
norma affidarsi ad algoritmi noti e ritenuti sicuri dagli esperti. Una delle
massime della crittografia recita: “La sicurezza di un crittosistema non deve
dipendere dal tener celato il crittoalgoritmo. La sicurezza dipenderà solo dal
tener celata la chiave.”

A margine di tutto, è comunque consigliabile limitare la gestione dei dati
critici: invece di cifrare i numeri delle carte di credito e conservarli, si
potrebbe chiedere agli utenti di inserire l’informazione quando necessario.

A9 – Denial of Service

Come tutti i servizi di rete, anche le applicazioni web, soffrono degli
attacchi di tipo DoS. (Denial of Service) in cui, attraverso l’esaurimento
delle risorse del sistema, si satura la sua capacità fino a determinarne il
blocco temporaneo. In questa situazione i sistemi diventano inutilizzabili per
gli utenti legittimamente attivi.

Una grossa quantità di richieste HTTP è un primo e semplice esempio di come
poter saturare le risorse di un server web, bloccando l’accesso per tutti gli
altri utenti. Pratiche di questo tipo sono sempre più frequenti durante i net
strike e, purtroppo, come meccanismo d’estorsione verso siti che traggono
profitto dalla pubblicità sul numero di visitatori.

Sebbene particolari configurazioni possono mitigare il problema, questa
problematica è comunque impossibile da risolvere. Si può attenuare un attacco
tramite potenziamenti dell’hardware, attraverso l’uso di load balancing e
instaurando accordi con i fornitori del servizio internet ma non è possibile
escludere il problema: l’aggressore potrebbe potenziarsi a sua volta oppure
attaccare risorse diverse (ampiezza di banda, numero di connessioni al database,
spazio su disco, utilizzo della CPU e della memoria e così via).

Come regola generale conviene limitare, a livello software, il massimo numero
di risorse allocate per un singolo utente.

A10 – Insecure Configuration Management

Gli esperti di OWASP inseriscono in ultima posizione, all’interno della OWASP
Top Ten, la classe di vulnerabilità ricollegabile all’errata configurazione dei
web server e degli application server. Sebbene questi errori non sono
strettamente legati alle applicazioni eseguite, una cattiva configurazione può
mettere a repentaglio, in termini di sicurezza, l’intero lavoro dello
sviluppatore.
Per completezza accenniamo comunque ai problemi più comuni:

• Software non aggiornati o bachi non ancora risolti all’interno dei
  servizi
• Presenza online di contenuti non necessari quali script di esempio,
  backup, file di configurazione, ecc
• Presenza di account noti con password di default
• Utilizzo improprio di permessi, privilegi
• Errata gestione degli errori e dei messaggi di errore (blocco
  dell’applicazione senza la gestione delle eccezioni e informazioni di debug
  visibili)

Da questo breve elenco risulta quindi evidente come sia indispensabile curare
la messa in opera dell’ambiente di fruizione, per evitare di sprecare tutti gli
sforzi fatti al fine di evitare le nove vulnerabilità precedenti evidenziate da
OWASP. La sicurezza di un sistema è determinata dalla sicurezza dell’elemento
più debole: trascurare anche un solo aspetto può determinare la perdita dei
nostri dati o della nostra riservatezza.