Elaborato Paesano Serena N46000600

Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in CALCOLATORI ELETTRONICI I
Analisi delle vulnerabilità di applicazioni
web
Anno Accademico 2016/2017
Candidato:
Serena Paesano
matr. N46/600
Indice
Indice..................................................................................................................................................................II
Capitolo 1:Le vulnerabilità di un sistema informatico e catalogo CVE.............................................................3
1.1 Le vulnerabilità.........................................................................................................................................3
1.2 Database di vulnerabilità..........................................................................................................................6
1.3 Common Vulnerabilities and Exposures..................................................................................................7
1.3.1 Struttura CVE....................................................................................................................................8
Capitolo 2: Owasp: linee guide per lo sviluppo di applicazioni sicure.............................................................12
2.1 Owasp development guide .....................................................................................................................12
2.2 Threat Risk Modeling.............................................................................................................................15
Capitolo 3:Owasp Top Ten Vulnerabilities......................................................................................................17
3.1Top Ten Vulnerabilities...........................................................................................................................17
Capitolo 4:ZAP ................................................................................................................................................26
4.1 Zap:Un caso d'uso...................................................................................................................................27
CAPITOLO 1 : Le vulnerabilità di un sistema informatico e catalogo CVE
Le minacce informatiche sono uno dei principali problemi dell’era digitale. L'enorme
sviluppo tecnologico che ha investito il mondo dei sistemi informatici ha portato alla
nascita di molti nuovi servizi, ma allo stesso tempo ha aperto le porte a nuovi, più
inquietanti scenari e possibilità di attacco che mirano a ledere la sicurezza di un sistema
informatico. Un ruolo importante all’interno di un sistema è quindi affidato alla sicurezza,
ossia la salvaguardia da minacce, malfunzionamenti, integrità dei dati e loro divulgazione.
La Sicurezza Informatica consiste in un insieme di misure di carattere organizzativo,
tecnologico e procedurale mirate a garantire 3 principi fondamentali:
• Segretezza/Confidenzialità: le informazioni possono essere lette solo da chi ne ha diritto.
• Integrità: le informazioni possono essere modificate solo da chi ne ha diritto.
• Disponibilità: una risorsa deve essere disponibile quando richiesta.
1.1 Le Vulnerabilità
La gestione del rischio informatico si svolge attraverso un articolato processo che mira a
identificare le vulnerabilità del sistema, le possibili minacce e la relativa probabilità di
accadimento nonché a stimare i potenziali danni.
Il rischio è calcolato in funzione di 3 fattori:minacce, impatto e vulnerabilità.
Una minaccia (Threat) è una potenziale causa di incidente che può danneggiare uno o
tutti i beni del patrimonio informativo.
3
L'impatto rappresenta il danno effettivo dell'incidente.
Una Vulnerabilità[1] rappresenta un difetto nella progettazione, nell’ implementazione di
un componente o nei controlli di sicurezza del sistema che può essere sfruttata,
intenzionalmente o meno, da un attaccante, per violare il sistema. Le vulnerabilità quindi
non compromettono un sistema, ma se utilizzate da una minaccia possono dar luogo ad un
evento indesiderato.
Non esiste una classificazione univoca delle vulnerabilità,essa dipende dal tipo di analisi
che si vuole condurre, ovvero dall'ambito di applicazione. Per quanto riguarda i sistemi
informatici,le vulnerabilità si possono presentare a qualsiasi livello che costituisce il
sistema. Una possibile classificazione è quella che raggruppa le vulnerabilità
principalmente in 3 categorie, che rappresentano tre diversi livelli da analizzare per la
sicurezza: la rete, i sistemi e gli applicativi.
Vulnerabilità di Rete: Per rete si intende tutta l’infrastruttura di comunicazione di un
sistema informativo, dal cablaggio ad apparati concentratori (hub/switch), fino al livello
dei protocolli per il trasporto. In modo particolare troviamo vulnerabilità a livello fisico
(sniffing) e vulnerabilità ad alto livello network (attacchi a protocolli di autenticazione,
attacchi per il blocco dei servizi(Denial Of Service - DOS)).
Vulnerabilità dei Sistemi: Per sistemi si intende tutto il software che controlla un
apparato hardware dotato di processore e memoria. I problemi di sicurezza sono legati al
fatto che i sistemi accettano connessioni dall’esterno, o scambiano informazioni tramite la
rete. Le relative vulnerabilità sono spesso causate da “buffer overflow”, scripting o
malfunzionamenti del sistema di autenticazione, che permettono accesso remoto al sistema
con tecniche conosciute con il nome di “exploit”.
Vulnerabilità delle Applicazioni: Per applicazione si intende tutto il software, compilato
od interpretato che è funzionante su di un sistema. Si definisce “servizio” un’applicazione
che rende disponibili delle informazioni via rete od in locale.. Fanno parte della categoria
4
applicazioni tutti i tools di posta elettronica e web, i programmi di autenticazione ed
accesso ai sistemi ed applicativi gestionali, servizi web server, file server, mail server ecc.
Le vulnerabilità maggiori e più pericolose sono relative ai servizi disponibili via rete, che
spesso permettono di accedere al sistema. Tra i software che sfruttano queste vulnerabilità
troviamo anche i più noti Virus, Trojans,Worms.
Le vulnerabilità hanno un proprio ciclo di vita scandito da varie fasi:
1. Creazione: la vulnerabilità nasce nel momento in cui viene scritto il codice e tale
codice viene rilasciato. Tuttavia in questa prima fase, la vulnerabilità pur esistendo
non è nota, quindi non rappresenta un problema.
2. Scoperta: La vulnerabilità viene scoperta, ma è nota solo a un gruppo ristretto di
individui. Tutta via questi cominciano a sfruttarla per attaccare i vari sistemi
vulnerabili.
3. Condivisione/Annuncio: Viene diffusa la conoscenza della vulnerabilità. In
questa fase spesso vengono anche creati automatismi per sfruttare la vulnerabilità,
non è quindi necessario essere degli esperti di hacking. In questa fase gli attacchi
crescono a dismisura.
4. Pubblicazione della patch: Viene creata la patch, ossia una correzione al codice
che mira a risolvere la vulnerabilità.. E’ interessante notare, che in questa fase, gli
attacchi continuano ad aumentare, per iniziare a scendere molto dopo che la patch
sia stata distribuita.
5. Installazione della patch: In questa fasi si procede all'installazione della patch e
alla risoluzione della vulnerabilità. Gli attacchi qui si annullano del tutto.
5
1.2 Database di vulnerabilità
Le vulnerabilità sono raccolte e descritte in database di informazioni. Un database di
vulnerabilità è una piattaforma volta a raccogliere,mantenere e diffondere informazioni
circa la scoperta di nuove vulnerabilità. Il database di norma conterrà informazioni quali
la descrizione della vulnerabilità identificata,il potenziale effetto sui sistemi informatici e
la soluzione necessaria.
Database di vulnerabilità o mailing list sono spesso presenti come documentazione di
supporto anche in molte applicazioni e tools volti a effettuare test di sicurezza.
Una delle voci presenti in molti database risulta essere quella dedicata allo Scoring. Per
determinare quantitativamente la gravità di una vulnerabilità esistono diverse tecniche: Il
Common Vulnerability Scoring System (CVSS)[2] è una delle tecniche più utilizzate dalla
maggior parte dei database di vulnerabilità. Il CVSS determina lo score da assegnare ad
una vulnerabilità basandosi su 3 tipi di metriche:

Base: rappresenta le caratteristiche di una vulnerabilità che sono costanti nel tempo
ed indipendenti dal contesto in cui si trovano. Informazioni di questo tipo sono ad
esempio l’impatto generato dalla vulnerabilità in termini di confidenzialità,
integrità e disponibilità.

Temporal: rappresenta le caratteristiche di una vulnerabilità che cambiano nel
tempo. Ad esempio perché le tecniche di uso (exploit) si raffinano, oppure perché
divengono disponibili rimedi (patch) alla vulnerabilità stessa

Environmental: rappresenta le caratteristiche di una vulnerabilità che sono rilevanti
rispetto al contesto utente in cui vengono considerate. Informazioni di questo tipo
comprendono l’impatto collaterale che la vulnerabilità genera se sfruttata da un
attaccante, come ad esempio una perdita finanziaria.
6
Dalla combinazione di queste 3 metriche si ottiene poi lo score definitivo,un valore
compreso tra 0 e 10, associato alla vulnerabilità.
1.3 Common Vulnerabilities and Exposures
Negli decenni passati la maggior parte dei tools di sicurezza informatica usavano i propri
database e i proprio nomi per le vulnerabilità di sicurezza. A quel tempo non c'era una
significativa variazione tra i prodotti e non c'era un modo semplice per determinare
quando database differenti si riferivano allo stresso problema. Le conseguenze erano
potenziali falle nella coperture della sicurezza e nessuna effettiva interoperabilità tra i
distinti database e tool. In più le vulnerabilità non erano standardizzate. E' stato il CVE ha
fornire una soluzione a questi problemi.
Il Common Vulnerabilities and Exposures[3], o CVE è un dizionario pubblico di
vulnerabilità e falle di sicurezza note. Il CVE è progettato per raccogliere e standardizzare
la classificazione delle vulnerabilità a livello mondiale,in modo tale da consentire a
database di vulnerabilità e altri sistemi di essere collegati insieme così da facilitare la
comparazione degli strumenti e servizi di sicurezza,e rendere più semplice la condivisione
delle informazioni. La lista di vulnerabilità CVE è pubblica,disponibile a chiunque sia
interessato a consultarla,scaricarla, farne riferimento o analizzarla,ma senza modificare le
informazioni in essa contenute.
Il processo per la creazione di un nuovo CVE comincia con la scoperta di una
vulnerabilità a cui viene assegnato un identificatore CVE da un authority CNA una volta
che questi è stato verificato.
7
1.3.1 Struttura CVE
Ogni vulnerabilità è associata ad un identificatore.
Gli identificatori CVE,detti anche nomi cve, cve-id, sono degli identificatori univoci
comuni per le vulnerabilità di sicurezza informatica di dominio pubblico.
Ogni identificatore CVE include:

Un numero identificativo CVE.

Una breve descrizione della vulnerabilità di sicurezza.

Tutti i riferimenti pertinenti ( ad esempio i rapporti di vulnerabilità).
Campi di un dato CVE
In un dato CVE sono presenti i seguenti campi:
Name
Contiene l'identificativo associato alla vulnerabilità.
La sintassi di un CVE-ID segue la forma: CVE prefisso + YYYY + NNNN.
Y rappresenta l'anno di pubblicazione e N un numero incrementale. Es.:CVE-2016-6319.
Dato l'aumento di vulnerabilità segnato ogni anno, dal gennaio 2015 è stata introdotto un
nuovo formato :CVE prefisso + YYYY + NNNN[N]{0,7}, dove questa volta N può
assumere fino a 7 cifre in modo tale da superare il limite di 9999 vulnerabilità annue
consentite nel precedente formato.
8
Description
Fornisce una breve descrizione della vulnerabilità.
Quando possibile, la descrizione include dettagli come il nome del prodotto interessato e
fornitore, un riepilogo delle versioni interessate, il tipo di vulnerabilità, l'impatto, i
permessi che un attaccante richiede per sfruttare la vulnerabilità, e i componenti di codice
o input che sono coinvolti. Tuttavia, dal momento che queste informazioni non sono
sempre disponibili al pubblico, non tutte le descrizioni includono tutti questi dettagli.
References
E' una lista di url e altre informazioni pertinenti la vulnerabilità. In ogni riferimento
utilizzato in CVE viene identificata la fonte, è incluso un identificatore ben definito per
facilitare la ricerca sul sito web della fonte, e sono presenti eventuali identificatori CVE
correlati.
Data Entry Created
Si riferisce alla data di quando la entry è stata inserita nella lista una volta che
l'identificatore candidato è stato approvato.
Phase
Indica la fase in cui si trova in CVE,ossia se è un candidato o una voce.
Votes
Conteneva un voto con cui si esprimeva la preferenza o meno riguardo il passaggio dei
candidati a voci effettive CVE.
9
Comments
Contiene commenti sulla vulnerabilità.
Proposed
Indica quando il problema è stato proposto per la prima volta.
Tuttavia, negli ultimi anni i campi di Votes, Comments e Proposed non sono più utilizzati
e vengono lasciati vuoti.
Ecco un esempio di una entry CVE:
10
Vantaggi di CVE
All'interno del catalogo CVE non troviamo informazioni circa i rischi,l'impatto,soluzioni
proposte,informazioni tecniche dettagliate o indici di sicurezza (es. score CVSS). Queste
sono tutte informazioni presenti già nei database di vulnerabilità e il CVE non vuole
replicarle. Il CVE ha invece il compito di fornire uno standard di vulnerabilità in modo
tale da facilitare la comunicazione tra i diversi database. La semplice conoscenza dell'
identificatore comune consente di accedere velocemente e accuratamente alle informazioni
sulla vulnerabilità, attraverso sorgenti di informazioni multiple che sono tutte compatibili
con CVE. Ad esempio se si possiede un tool di sicurezza i cui rapporti contengono
riferimenti a identificatori CVE,viene fornita la possibilità di accedere facilmente a
informazioni corrette in un database differente che è anch'esso compatibile con CVE.
Gli identificatori CVE inoltre forniscono una base di riferimento per la valutazione della
copertura degli strumenti e dei servizi così che gli utenti possono determinare quale tool è
il più efficace e appropriato in base alle proprie esigenze. In breve,prodotti e servizi
compatibili con CVE forniscono migliore copertura,un'interoperabilità più semplice e una
maggiore sicurezza.
11
CAPITOLO 2 Owasp: Linee guida per lo sviluppo di applicazioni sicure
Applicazioni e servizi web sono diventati lo strumento più popolare attraverso cui un
numero sempre crescente di organizzazioni decide di interfacciarsi con il mondo esterno.
L'enorme aumento di applicazioni web in svariati campi di azione,e-commerce,social
networking, web search, web mail,banking ecc,ha portato all'aumento dei requisiti
necessari alla sicurezza di internet,dei dati e delle applicazioni web.
La progettazione e l'implementazione di funzionalità di sicurezza all'interno di
applicazione web è sicuramente un compito molto complesso e troppo spesso
sottovalutato da analisti e sviluppatori. Purtroppo la sicurezza non è una semplice
componente che può essere facilmente aggiunta ad un software già sviluppato,ma è parte
integrante del processo della progettualità stessa di un applicativo. Pertanto la sicurezza di
un'applicazione dovrebbe partire dalle basi: aziende e sviluppatori dovrebbero porsi
l'obiettivo di progettare e sviluppare un'applicazione che sia sicura. In questo contesto si
colloca l'opera del gruppo Owasp: fornire delle linee guida per lo sviluppo sicuro di
applicazioni web, ad uso e consumo di analisti,progettisti e sviluppatori.
2.1 Owasp Development Guide[4]
Non è possibile sviluppare un'applicazione sicura senza aver progettato un'architettura di
sicurezza. E' proprio l'architettura di sicurezza che consente all'applicazione di garantire i
principi di integrità,disponibilità e confidenzialità dei dati che costituiscono i pilastri
fondamentali della Information Security. Le applicazioni dovrebbero quindi fornire una
12
serie di controlli diversi e complementari per proteggere la riservatezza delle
informazioni,l'integrità dei dati, e garantire l'accesso alle informazioni solo agli utenti che
ne hanno diritto quando essi ne fanno richiesta. Accanto a questo principio base,Owasp
propone delle linee guida per lo sviluppo e progettazioni di applicazioni web sicure.
Minimizzare l'area della "superficie di attacco"
Ogni caratteristica aggiuntiva di un'applicazione introduce inevitabilmente una certa
quantità di rischio per l'intero progetto. L'obiettivo dello sviluppo sicuro è quello di ridurre
il rischio globale riducendo la "superficie di attacco". Per esempio un'applicazione web
che implementa help online con funzione ricerca,può essere vulnerabile ad attacchi di tipo
SQL injecton. Se la funzione help fosse limitata agli utenti autorizzati, le probabilità di
attacco sarebbero ridotte. Se la funzionalità di help fosse poi anche interfacciata con un
modulo centralizzato di validazione dei dati,le possibilità di eseguire Sql Injecton
sarebbero ridotte drasticamente.
Principio del Secure by default
L'applicazione dovrebbe utilizzare caratteristiche di sicurezza di default: per esempio
l'abilitazione automatica di meccanismi di costruzione di password di una certa
complessità contro il password guessing ed il rinnovo delle password secondo una
scadenza temporale.
Principio del Least Privilege
Il principio del Least Privilege raccomanda che gli utenti ( e più in generale gli stessi
applicativi) abbiano l'insieme minimo dei privilegi richiesti per eseguire correttamente il
proprio lavoro. Ciò riguarda, ad esempio, la possibilità per un utente di interagire con le
funzionalità critiche di un applicativo, di lanciare altri programmi, di avere i permessi di
accesso al database e al file system,di avere i diritti di accesso alle risorse fisiche quali
13
rete, memoria, CPU. Questo principio del tutto generale limita il danno che può risultare
in caso di errore, o di utilizzo non autorizzato dell'applicativo.
Principio del Defense in depth
Il principio del Defense in Depth attesta che dove un solo controllo dovrebbe essere
ragionevole, più controlli che contrastano i rischi in maniera differente sono sicuramente
migliori. Quando viene utilizzata una simile strategia, si rende estremamente difficile la
possibilità per un attaccante di sfruttare una singola vulnerabilità di un singolo sistema.
Terminare in modo "sicuro"
Le applicazioni possono terminare per diversi motivi i propri processi: il modo in cui
avviene questa terminazione determina se l'applicativo è sicuro o meno.
Per esempio,consideriamo il seguente codice:
isAdmin = true;
try {
codeWhichMayFail();
isAdmin = isUserInRole( “Administrator” ); }
catch (Exception ex) {
log.write(ex.toString()); }
Se codeWhichMayFail() fallisce, l'utente è l'amministratore per default. Questo è
ovviamente un rischio di sicurezza da evitare.
Considerare i sistemi esterni come insicuri
Molte organizzazioni utilizzano processi e/o comunicano con i propri partner durante le
fasi del proprio business. Questi partner avranno differenti politiche ed un diverso
approccio alla sicurezza e devono pertanto essere considerate terze parte non fidate: risulta
invece prassi comune fornire una fiducia implicita verso sistemi esterni, senza considerare
i rischi derivanti da tale scelta.
14
Principio della Separation of Duties
La separazione dei compiti, cioè l'assegnazione a utenti diversi di parti distinte di un
processo critico,è un controllo chiave nel campo delle frodi. Questo controllo previene
numerose frodi perché, se il processo prevede che più utenti abbiano il controllo dei
meccanismi di sicurezza, il rischio di compromettere l'intera infrastruttura viene
notevolmente ridotto.
Non fidarsi del " Security Through Obscurity"
Nel modello di sicurezza indicato in letteratura come Security Through Bbscurity un
sistema è considerato sicuro semplicemente perché si ritiene che nessuno ne conosca i
dettagli. Tale approccio porta alla realizzazione di controlli di sicurezza che alla lunga
risultano deboli, e fallisce quando è il solo ad essere implementato. La sicurezza di un
sistema non può dipendere esclusivamente dal riuscire a mantenere nascosti i dettagli sul
sistema stesso, e così la sicurezza di un'applicazione non risiede nella segretezza del
codice sorgente. Bisogna invece sempre presupporre che un attaccante sia in possesso di
tutte le nostre informazioni: assumere cioè che abbia accesso al codice o alla
documentazione del progetto.
2.2 Threat Risk Modeling
Un elemento fondamentale per creare un'architettura sicura è il Threat Modeling. Il Threat
Modeling di un applicativo web è un'analisi sistematica che aiuta sviluppatori ed analisti
ad identificare e valorizzare in modo ordinato le minacce che potrebbero affliggere
l'applicativo e in che modalità si potrebbero manifestare gli attacchi. Gli obiettivo di tale
processo sono:

identificare le minacce più gravi da contrastare e partire da quest'ultime per
mitigare il rischio, selezionando i controlli di sicurezza più efficaci.

fornire un approccio strutturato e più efficiente dal punto di vista dei costi.
15
Il processo di Threat Modeling si compone dei seguenti passi:
La valutazione degli asset, è il punto di partenza per tutte le attività di analisi e valutazione
del rischio, poiché dal valore che realmente hanno gli asset, ossia le risorse, scaturiscono
le considerazioni sulla tipologia di controlli di sicurezza da implementare e sui loro gradi
di efficacia.
Creare
una
visione
dell'architettura.
Inizialmente
si
identifica
cosa
fa
l'applicazione,successivamente si crea un diagramma dell'applicazione che mostri i
sottosistemi,il flusso dei dati, la lista degli asset ed un diagramma architetturale che
scomponga l'applicativo.
Scomporre l'identificativo. Si procede al raffinamento del diagramma architetturale
mostrando il meccanismo di autenticazione, il meccanismo di autorizzazione, le tecnologie
utilizzate, gli entry point. Avendo ora a disposizione una fotografia dello scenario, ci si
pone dal lato di un possibile attaccante cercando di capire dove sono le possibili
vulnerabilità e quali contromisure sono in atto per eliminarle.
Identificare le minacce. In questa fase si crea una lista delle possibili minacce e si
identificano quelle che andranno ad impattare sull'applicazione in oggetto.
Documentare le minacce. Si documentano l'insieme delle minacce identificando, per
ciascuna minaccia, l'obiettivo, la tecnica di attacco utilizzata e le contromisure da adottare.
Misurare le minacce. Il processo di Threat Modeling termina quantificando ogni singola
minaccia e misurando il rischio associato. La determinazione del rischio viene fatta
affidandosi a formule o modelli appositi.
La progettazione è solamente una parte del processo di creazione di applicazioni web
sicure. Supporto esecutivo,implementazione, testing, creazione e consegna, nonché
fornitura e manutenzione giocano tutti un ruolo cruciale nella protezione finale di un
sistema ed è solo inserendo la sicurezza in ogni singola fase dell'intero processo di
sviluppo del ciclo di vita di un applicativo che si possono realizzare applicazioni sicure.
16
CAPITOLO 3 OWASP TOP TEN VULNERABILITIES
Il progetto OWASP Top Ten è una classifica delle 10 vulnerabilità più comuni e più
pericolose a cui possono essere soggette al giorno d'oggi le applicazioni web. La guida si
focalizza sull'identificare i rischi più gravi per una vasta gamma di organizzazioni. Per
ognuno di questi rischi vengono fornite poi informazioni utilizzando degli schemi di
valutazione che tengono conto di: vettore di attacco, diffusione, individuazione e impatto
tecnico. Gli agenti di minaccia presentati nella guida dipendono dalle specifiche
applicazioni,pertanto
ogni
azienda
dovrebbe
valutare
focalizzandosi sugli aspetti caratteristici della propria impresa.
3.1 Top Ten Vulnerabilities[5]
Le 10 vulnerabilità più rischiose elencate da Owasp sono :

A1- Injection.

A2 - Broken Authentication and Session Management.

A3 - Cross-Site Scripting (XSS).

A4 - Insecure Direct Object References.

A5 - Security Misconfiguration.

A6 - Sensitive Data Exposure.
17
personalmente
il
rischio

A7 - Missing Fnction Level Access Control.

A8 - Cross-Site Request Forgery (CSRF).

A9 - Using Components with Known Vulnerabilities.

A10 - Unvalidated Refirects and Forwards.
A1 - INJECTION
Le Injection Flaws,si verificano quando dati non validati sono inviati come parte di un
comando o di una query al loro interprete. Il dato infetto può quindi ingannare tale
interprete, eseguendo comandi non previsti o accedendo a dati per i quali non si ha
l'autorizzazione.
Sfruttabilità Facile. L'attaccante invia del semplice testo che sfrutta la sintassi
dell'interprete. Ogni sorgente di dati può essere un vettore di Injection, comprese le
sorgenti interne.
Diffusione:Comune
-
Individuazione:Medio.
Un'injection
si
verifica
quando
un'applicazione invia dei dati non fidati ad un interprete. Tali debolezze sono spesso
presenti nel codice legacy, principalmente nelle query SQL, LDAP,nei comandi OS, negli
Header SMTP, nei parametri dei programmi ecc. E' più facile individuare un'injection
tramite analisi del codice che tramite testing.
Impatto: Severo. Un' Injection può comportare perdita o corruzione di dati,mancanza di
tracciabilità,negazione d'accesso e, in alcuni casi il controllo completo dell'host.
Il miglior modo per individuare se un'applicazione è vulnerabile a Injection è verificare
che, ogni volta che l'interprete è ingaggiato, ci sia una separazione netta tra i dati non fidati
e i comandi/query. Per le chiamate SQL, ciò significa utilizzare variabili "blinded" negli
statement e nelle stored procedure, evitando l'uso di query generate dinamicamente.
18
A2 - BROKEN AUTHENTICATION AND SESSION MANAGEMENT
Le procedure applicative relative all'autenticazione e alla gestione della sessione sono
spesso implementate in modo non corretto, permettendo agli attaccanti di compromettere
password,chiavi, token di sessione o sfruttare debolezze implementative per assumere
l'identità di altri utenti.
Sfruttabilità: Medio. L'attaccante usa difetti nel sistema di gestione della sessione o
dell'autenticazione ( es. : esposizione delle password o degli account, identificativi di
sessione, ecc.) per impersonare l'utente.
Diffusione: Diffuso - Individuazione: Medio. Approcci personalizzati di gestione della
sessione e autenticazione spesso contengono difetti in varie aree quali il logout, i timeout,
il ricordarmi su questo computer", la domanda segreta, ecc. Scoprire tali difetti può essere
difficile, in quanto ogni implementazione è unica.
Impatto: Severo. Tali difetti possono consentire un accesso diretto verso uno o più
account. In caso di successo l'attaccante ottiene gli stessi privilegi della vittima.
A3 - CROSS-SITE SCRIPTING (XSS)
Le falle di tipo XSS si verificano quando un'applicazione web riceve dei dati, provenienti
da fonti non affidabili, e li invia ad un browser senza una opportuna validazione e/o
"escaping". Il XSS permette agli attaccanti di eseguire degli script malevoli sui browser
delle vittime; tali script possono dirottare la sessione dell'utente, defacciare il sito web o
re-indirizzare l'utente su un sito malevolo.
Sfruttabilità: Medio. Si inviano sequenze di comandi testuali(script) per forzare
l'interprete interno del browser. Quasi tutte le sorgenti di dati possono essere vettori di
attacco,anche quelle interne(es. database interni).
Diffusione: Molto diffuso - Individuazione : Facile. Il XSS è il più diffuso difetto di
sicurezza delle applicazioni web. Questa vulnerabilità si manifesta quando un applicativo
19
genera una pagina includendo dati forniti dall'utente senza averli prima validati o aver
fatto l'escaping del contenuto. I difetti di XSS sono semplici da trovare attraverso l'analisi
ed il testing del codice.
Impatto: Moderato. L'attaccante può eseguire del codice all'interno del browser della
vittima allo scopo di: impadronirsi della sessione della vittima, defacciare un sito web,
inserire contenuti ostili, reindirizzare, ecc. Una copertura completa della problematica
richiede, oltre all'uso di tool automatici, revisione manuale del codice e dei penetration
test.
A4 - INSECURE DIRECT OBJECT REFERENCES
Quando uno sviluppatore espone un riferimento all'implementazione interna di un oggetto,
come un file, una directory o una chiave di un database, si ha un riferimento diretto ad un
oggetto. Senza un opportuno controllo degli accessi o altre protezioni, gli attaccanti
possono manipolare questi riferimenti in modo da accedere a dati non autorizzati.
Sfruttabilità: Facile. L'attaccante, da utente autorizzato, cambia il valore di un parametro,
che riferisce direttamente ad un oggetto di sistema, con un altro oggetto a cui non è
autorizzato ad accedere.
Diffusione: Comune - Individuazione: Facile. Le applicazioni di solito utilizzano il nome
reale o chiave di un oggetto quando generano pagine web. Le applicazioni non sempre
verificano se l'utente è autorizzato o meno ad accedere ad un oggetto specifico. Questo
comporta difetti di riferimento di accesso diretto non sicuro agli oggetti. I tester possono
facilmente manipolare i valori dei parametri per rilevare questi difetti. L'analisi del codice
mostra rapidamente se l'autorizzazione viene verificata in modo corretto. Gli strumenti
automatici di solito non ricercano questi difetti perchè non possono riconoscere cosa
debba essere protetto o se è sicuro o meno.
20
Impatto:Severo. Tali falle possono compromettere tutti
dati che possono essere
referenziati da un parametro. A meno di riferimenti ad oggetti non predicibili, è facile per
un attaccante accedere a tutti i dati disponibili di questo tipo.
A5 - SECURITY MISCONFIGURATION
Una buona sicurezza richiede un'opportuna configurazione impostata e sviluppata per
applicazioni, framework, server applicativi, webserver, database e piattaforme. Tutte le
configurazioni devono essere definite, implementate, mantenute in quanto le
configurazioni di default non sono sempre sicure. Inoltre tutto il software deve essere
sempre aggiornato.
Sfruttabilità: Facile. Gli attaccanti accedono al sistema tramite utente di default, pagine
non utilizzate, difetti non sanati, file e directory non protette,ecc.
Diffusione: Comune - Individuazione: Facile. Errate configurazioni di sicurezza possono
avvenire a qualsiasi livello della pila applicativa. Gli sviluppatori e gli amministratori
devono lavorare insieme per assicurare la corretta configurazione del sistema. Scanner
automatici consentono l'individuazione di patch mancanti, errate configurazioni, account
di default, servizi non necessari.
Impatto:Moderato. Questo tipo di difetto può fornire accesso a dati di sistema o ad alcune
funzionalità. In alcuni casi, tali debolezze, portano ad una totale compromissione del
sistema.
A6 - SENSITIVE DATA EXPOSURE
Molte applicazioni web non proteggono adeguatamente dati quali numeri di carte di
credito o credenziali di autenticazione. Gli attaccanti possono impossessarsi di tali dati o
approfittare dei punti deboli nelle misure di protezione per il furto di credenziali, per
21
operazioni fraudolente. Questo tipo di dati necessitano di misure di protezione
ulteriori,come la crittografia anche per i dati in transito, nonché speciali precauzioni
quando vengono scambiati con il browser.
Sfruttabilità: Difficile. Generalmente un utente malevolo non rompe direttamente un
cifrario, ma ruba le chiavi crittografiche, fa attacchi di tipo man-in-the-middle o intercetta
i dati in chiaro in transito o direttamente tramite il browser dell'utente.
Diffusione:Non comune - Individuazione: Medio. L'errore più comune è non cifrare le
informazioni confidenziali. Invece, quando queste sono cifrate, altri errori molto diffusi
sono : l'utilizzo di chiavi poco robuste, algoritmi o tecniche di hashing delle password
deboli.
Impatto: Severo. Spesso le vulnerabilità compromettono dati che dovrebbero essere
protetti. Tipicamente questi dati comprendono cartelle sanitarie, credenziali di accesso,
carte di credito, dati personali, ecc.
A7 - MISSING FUNCTION LEVEL ACCESS CONTROL
Molte applicazioni verificano il livello dei diritti di accesso prima che la relativa
funzionalità sia resa visibile nell'interfaccia utente. Tuttavia, le applicazioni devono
eseguire il controllo accessi sul server ogni volta che la funzionalità è acceduta. Se le
richieste di accesso non sono verificate, gli attaccanti possono falsificarle per accedere
senza autorizzazione alle funzionalità.
Sfruttabilità: Facile. E' importante porsi le seguenti domande: Se l'attaccante cambia
l'URL o un parametro di una funzione privilegiata, si ottiene l'accesso? Gli utenti anonimi
possono accedere a funzionalità private non protette?
Diffusione:Comune - Individuazione:Medio. Le funzionalità delle applicazioni non sono
sempre protette come dovrebbero. A volte l'accesso alle funzionalità è gestito tramite file
di configurazione e sono presenti problematiche nella configurazione. In altri casi gli
sviluppatori devono includere dei controlli nel codice e se ne dimenticano. Individuare
22
questo tipo di problematiche è facile. La difficoltà è individuare le pagine (URL) o le
funzionalità da attaccare.
Impatto: Severo. Queste vulnerabilità consentono l'accesso non autorizzato alle
funzionalità. Solitamente le funzionalità più attaccate in questo modo sono quelle
amministrative.
A8 - CROSS-SITE REQUEST FORGERY ( CSRF)
Un attacco CSRF forza il browser della vittima ad inviare una richiesta HTTP
opportunamente forgiata, includendo i cookie di sessione della vittima ed ogni altra
informazioni di autenticazione, ad un'applicazione web vulnerabile. Questo permette
all'attaccante di forzare il browser della vittima a generare richieste che l'applicazione
vulnerabile crederà legittimamente inviate dalla vittima.
Sfruttabilità: Medio. L'attaccante forgia delle richieste HTTP e spinge la vittima a
inviarle tramite tag image, XSS, o altre tecniche. Se l'utente è autenticato, l'attacco ha
successo.
Diffusione: Comune - Individuazione: Facile. Il CSRF approfitta del fatto che la maggior
parte delle applicazioni permette agli attaccanti di essere a conoscenza di tutti i dettagli di
una particolare azione. Poiché i browser inviano le credenziali automaticamente,
l'attaccante può creare pagine web malevoli per generare delle richieste forgiate,
impossibili da distinguere da quelle lecite. E' abbastanza facile identificare CSRF tramite
un penetration test o una code analysis.
Impatto: Moderato. Gli attaccanti possono spingere le vittime ad eseguire qualsiasi
cambio di stato se la vittima è autorizzata a farlo, es. eseguire acquisti,eseguite logout e
login.
23
A9 - USING COMPONENTS WITH KNOWN VULNERABILITIES
Componenti quali librerie, framework e altri moduli software sono quasi sempre eseguiti
con i privilegi più alti. Sfruttando un componente vulnerabile, un attaccante potrebbe
ottenere dei dati o accedere al server. Le applicazioni che utilizzano componenti con
vulnerabilità note possono minare le loro difese agevolando molte tipologie di attacco con
impatti notevoli.
Sfruttabilità:Medio. L'attaccante identifica tramite scanner o manualmente un
componente vulnerabile. Personalizza l'exploit ed esegue l'attacco. Se il componente è
integrato nell'applicazione si complica il tutto.
Diffusione:Diffuso - Individuazione: Difficile. Virtualmente, ogni applicazione ha questo
problema perché la maggior parte dei team di sviluppo non si focalizza sull'assicurarsi che
i propri componenti o librerie siano aggiornati.
Impatto:Moderato. L'intera gamma di problematiche è possibile, come Injection, XSS e
broken access control. L'impatto può variare da parziale a completa compromissione
dell'host e dei dati.
A-10 UNVALIDATED REDIRECTS AND FORWARD
Le applicazioni web spesso reindirizzano o inoltrano gli utenti verso altre pagine o siti ed
usano dati non validati per determinare le pagine di destinazione. Senza un'opportuna
validazione, gli attaccanti possono re-indirizzare le vittime verso siti di phishing o di
malware o utilizzare il forward per accedere a pagine non autorizzate.
Sfruttabilità: Medio. L'attaccante forza la vittima a cliccare su un link con un redirect non
validato. Le vittime sono propense a cliccare poiché il link appartiene a un sito valido.
L'attaccante punta ai forward insicuri per bypassare i controlli di sicurezza.
24
Diffusione: Non Comune - Individuazione: Facile. Rilevare redirect controllati è
semplice. E' sufficiente cercare i redirect dove si può impostare l'URL completo. I forward
non controllati non sono più difficili da individuare perché puntano a pagine interne.
Impatto:Moderato. Tali redirect possono installare malware o chiedere agli utenti di
inserire credenziali o altre informazioni sensibili.
Le vulnerabilità a cui può essere soggetta un'applicazione web non si limitano alle 10
elencate nella guida TOP TEN di Owasp. Tuttavia risultano essere le più comuni e le più
critiche per gli applicativi. In particolar modo la vulnerabilità più diffusa che colpisce le
applicazione rientra nella categoria delle SQL Injection.
25
CAPITOLO 4: ZAP
Nei capitoli precedenti sono state introdotte le linee guida che conducono allo sviluppo di
applicazioni sicure, in particolare è stato evidenziato quanto sia importante introdurre la
sicurezza in fase di progettazione. Tuttavia ciò non basta a garantire la sicurezza di un
applicativo, e per questo motivo gli sviluppatori possono contare sull'aiuto di tutta una
serie di strumenti che consentono di effettuare penetration testing e quindi verificare la
sicurezza dell'applicazioni. Uno strumento che consente di fare ciò è ZAP (Zed Attack
Proxy), un tool di sicurezza fornito da gruppo Owasp, gratuito e open-source, progettato
appositamente per testare le applicazioni web. Zap si pone quindi come strumento a
supporto di sviluppatori di applicazioni web che vogliono verificare la sicurezza del
proprio applicativo. Zap in particolare effettua un'analisi di vulnerability assessment,
26
pertanto individua le vulnerabilità presenti in un'applicazione e sulla base dei risultati
ottenuti è possibile stabilire le strategie e le manovre da adottare per rendere sicure le
proprie applicazioni. Fornisce un' ampia gamma di funzionalità che consentono di
effettuare analisi profonde e dettagliate,modellate sulle caratteristiche del caso specifico.
4.1 Zap: Un caso d'uso
E' presentato ora un caso d'uso nel quale ci si avvale di Zap per individuare la presenza di
vulnerabilità di tipo Sql Injection. E' stata creata quindi un'ambientazione volutamente
vulnerabile al fine di riscontrare questo tipo di vulnerabilità.
Cominciamo con la configurazione di Zap come server proxy: in questo modo è possibile
vedere tutte le richieste fatte all'applicazione web e tutte le risposte ricevute,zap quindi
opera collocandosi tra il browser e l'applicazione così da essere in grado di interpretare e
ispezionare i messaggi mandati tra le due parti parte,modificarne il contenuto se è
necessario e poi inoltrare i pacchetti alle destinazione. Dopo la configurazione iniziale, si
procede con l'analisi dell'applicazione web interessata.
Spider e Scansione Attiva
Nella schermata principale,a sinistra, è possibile notare la finestra siti, da questa
selezioniamo l'applicazione web che vogliamo testare.
L'analisi vera e propria dell'applicazione si articolare in due passi : Spider e Scansione
Attiva. Lo spider consente automaticamente di trovare nuove risorse (URL) in un
27
particolare sito esaminando le risponde html provenienti dall'applicazione: comincia con
una lista di url da visitare, chiamati seeds, quindi visita questi url, identifica tutti gli
ipertesti nella pagina e li aggiunge poi alla lista di url da visitare. Il processo continua
ricorsivamente fintantoché nuove risorse sono trovate. In questo modo siamo in grado di
individuare le pagine che compongono il sito. Nel caso d'interesse selezioniamo i
collegamenti che interessano e per i quali si vogliono trovare le vulnerabilità che
compongono il sito.
Si procede poi con la Scansione Attiva: In questa fase si tenta di trovare le potenziali
vulnerabilità utilizzando attacchi conosciuti applicati sui target selezionati. Si procede
selezionando quindi i target interessati e avviando la scansione attiva.
28
Alla fine della scansione attiva, nella sezione Avvisi, sono riportati i risultati organizzati
per priorità. Cliccando due volte su un avviso si apre una finestra che fornisce una serie di
informazioni sulla vulnerabilità trovata: l'url a cui si è verificata la vulnerabilità, il rischio,
la descrizione,la possibile soluzione e di particolare importanza, l'attacco condotto e il
parametro attaccato.
Dal risultato della scansione risulta che sono stati individuati avvisi ad alta priorità di tipo
Sql Injection.
Tramite la finestra delle informazioni possiamo conoscere gli attacchi e i parametri su cui
essi sono stati effettuati.
29
ATTACCO 1 - BYEPASS LOGIN
Si vuole ora procedere con l'exploit delle vulnerabilità trovate. Apriamo quindi l'url
corrispondente alla prima vulnerabilità individuata. E' una pagina che effettua il login
degli utenti. Procediamo inserendo nel campo nome un valore arbitrario, ad esempio
ADMIN, e nel campo password il comando suggerito da zap che genera la vulnerabilità.
Se procediamo con l'autenticazione, è possibile notare che questa è avvenuta correttamente
30
ATTACCO 2 - SHOW DATABASE
Procediamo con l'exploit di un'altra vulnerabilità individuata da zap. La pagina in esame
contente effettuare la ricerca di un elemento presente in un database. Si apre quindi
nuovamente l'url associato e si inserisce il comando suggerito da zap nel campo
opportuno.
E' possibile notare che il comando inserito ha avuto l'effetto di far visualizzare l'intero
database.
31
Contromisure
E' possibile mettersi al riparo da questo tipo di vulnerabilità adottando delle semplici
contromisure. Per attacchi a funzionalità di login si può ricorrere ad una funzione che
effettua l'escape di tutti i caratteri potenzialmente dannosi(per esempio l'apice singolo ').
Ad esempio, la query vulnerabile :
SELECT * FROM login WHERE name='admin' AND password='1' OR '1'='1' ,con la
funzione che effettua l'escape diventa:
SELECT * FROM login WHERE name='admin' AND password='1\ ' OR \'1\ '=\'1' , la
quale non produce alcun risulto.
Conclusioni
Da questo esempio si è potuto constatare che l'applicazione web testata è soggetta a due
semplici ma importanti vulnerabilità di tipo Sql Injection : Una consente l'autenticazione
di utenti non autorizzati e l'altra invece fornisce totale visione degli elementi che
compongono un database. Sono pertanto stati violati i principi di sicurezza e integrità dei
dati. Seppur semplice questo esempio mostra chiaramente quali più gravi conseguenze
potrebbero avere vulnerabilità di questo tipo se fossero presenti in applicazioni web di più
grande rilievo e impatto. E' pertanto di fondamentale importanza che aziende,società e
sviluppatori prestino sempre più attenzione e cura alla progettazione di applicazioni web
sicure.
32
Bibliografia
[1] Owasp foudation, www.owasp.org
[2] Common Vulnerabilities Scoring System, www.first.org/cvss
[3] Common Vulnerabilites and Exposures, www.cve.mitre.org
[4] Owasp Group, Owasp developmente guide, luglio 2005
[5] Owasp Group, Owasp Ton Ten, 12 giugno 2013
33