Sicurezza Informatica nello sviluppo di applicazioni in - INFN-LNF

A-PDF Split DEMO
Univesità di Roma Tor Vergata
Ingegneria dell’Informazione - Ind. Sistemi
Sicurezza Informatica
nello sviluppo di applicazioni web in L.A.M.P.
Emanuele Turella
Relatore:
Prof.ssa Berta Buttarazzi
Correlatori:
Dott.ssa Marina Candusso
Dott. Fabrizio Murtas
Anno Accademico 2004 / 2005
A-PDF Split DEMO
Sii il cambiamento che vuoi vedere
avvenire nel mondo
(Gandhi)
Ringraziamenti
Un grazie particolare alla mia famiglia
per avermi dato fiducia e la possibilità
di fare tutto questo.
A-PDF Split DEMO
Indice
Sommario
4
1 Concetti fondamentali
1.1 Le architetture distribuite . . . . . . . . . . .
1.1.1 La rete . . . . . . . . . . . . . . . . . .
1.1.2 L.A.M.P. . . . . . . . . . . . . . . . . .
1.2 Le applicazioni Web . . . . . . . . . . . . . .
1.3 Cosa intendiamo per sicurezza . . . . . . . . .
1.3.1 Vulnerabilità, minaccia e rischio . . . .
1.3.2 Le sicurezza su più livelli . . . . . . . .
1.3.3 Costo dei rischio e costo della sicurezza
2 Tecniche di attacco
2.1 Information gathering - Messaggi ed errori
2.2 Cross-Site scripting . . . . . . . . . . . . .
2.3 Cross-Site request forgiers . . . . . . . . .
2.4 SQL Injection . . . . . . . . . . . . . . . .
2.5 Parameter Tampering . . . . . . . . . . . .
2.6 Manipolazione degli header HTTP . . . .
2.7 Brute force . . . . . . . . . . . . . . . . .
2.8 Known vulnerabilities . . . . . . . . . . . .
2.9 Directory traversal e Path Disclosure . . .
2.10 Session Fixation . . . . . . . . . . . . . . .
2.11 Session hijacking . . . . . . . . . . . . . .
2.12 Cookie poisoning . . . . . . . . . . . . . .
2.13 Esecuzione di comandi di sistema . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
8
11
15
17
17
18
22
.
.
.
.
.
.
.
.
.
.
.
.
.
24
24
25
26
27
29
29
30
31
32
32
35
36
36
3 Tecniche specifiche per la difesa
37
3.1 INFN Forum . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2
A-PDF Split DEMO
INDICE
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3
3.1.1 Specifiche iniziali . . . . . . . . . . . . . . . . . .
Progettazione del Database . . . . . . . . . . . . . . . .
Linee guida . . . . . . . . . . . . . . . . . . . . . . . . .
Validazione dei dati . . . . . . . . . . . . . . . . . . . . .
3.4.1 Contromisure specifiche per... . . . . . . . . . . .
Sistema delle autorizzazioni . . . . . . . . . . . . . . . .
3.5.1 Controllo degli accessi . . . . . . . . . . . . . . .
3.5.2 Autenticazione . . . . . . . . . . . . . . . . . . .
Gestione delle sessioni . . . . . . . . . . . . . . . . . . .
3.6.1 Un esempio di autenticazione robusta . . . . . . .
Gestione degli errori . . . . . . . . . . . . . . . . . . . .
Riutilizzo del codice ed integrazione di prodotti affidabili
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
39
39
42
43
43
44
46
48
50
50
52
4 Conclusioni
54
Appendici
56
A Logging e gestione delle sessioni
56
B Validazione dei dati in input
60
C Autenticazione
71
Ringraziamenti
73
Bibliografia e Riferimenti
74
Bibliografia
74
A-PDF Split DEMO
Elenco delle figure
1.1
1.2
1.3
1.4
1.5
1.6
Rete locale con collegamento ad Internet . . . .
Modello OSI / ISO . . . . . . . . . . . . . . . .
Semplice schematizzazione dell’interazione client
Flusso dati di un web server con php . . . . . .
Applicazione web three-tier . . . . . . . . . . .
Rappresentazione estesa del client . . . . . . . .
.
.
.
.
.
.
9
10
13
14
16
20
2.1
Flow chart di un attacco session fixation . . . . . . . . . . . .
34
3.1
3.2
Struttura Entità-Relazioni della base di dati . . . . . . . . . .
Tabelle accessorie per lo sviluppo dell’applicazione . . . . . . .
40
41
4
. . . . . . .
. . . . . . .
- web server
. . . . . . .
. . . . . . .
. . . . . . .
A-PDF Split DEMO
Sommario
L’efficienza del Web sia come mezzo di divulgazione ché come mezzo di vendita
di prodotti e servizi è ormai nota a tutti. La rivoluzionaria affermazione di
questo nuovo strumento basato sull’elaborazione distribuita ha creato nuove
opportunità ma contestualmente ha esposto i dati, i sistemi e l’immagine dei
soggetti coinvolti.
Internet, però, è un mondo con le sue regole e accessibile a tutti: utenti inesperti ed inconsapevoli; gente che cerca di farsi un nome scoprendo
vulnerabilità, distruggendo dati e facendo soldi in modo illegale.
Se fino ad oggi le principali minacce alla sicurezza veniva dalla infrastruttura di rete e dai sistemi operativi, la diffusione delle applicazioni web ha creato nuovi quanto pericolosi obiettivi. Infatti, oltre alle conseguenze derivanti
dalla offerta di un servizio tramite web, si devono fronteggiare i rischi legati
al furto di informazioni e di indentità digitali od alla violazione delle banche
dati (vedi il furto dei numeri di carta di credito avvenuto solo poche settimane
fa).
Sfortunatamente non esistono dei rimedi nè delle tecniche tali da poter
rendere sicuro al 100% un servizio contro gli attacchi provenienti dall’esterno
ma, ciò nonostante, si può ancora operare per tenere lontani molti problemi.
In questa tesi si discutono le problematiche legate alla sicurezza provando
a concentrarsi sull’ottica del progettista e dello sviluppatore di software su
piattaforme distibuite.
Nella breve introduzione si farà una panoramica sufficientemente dettagliata dell’infrasfruttura distribuita con un accenno allo stato dell’arte nel
campo della sicurezza.
Nel secondo capitolo verranno presentate le tecniche di attacco in modo
tale da focalizzare i tipi di vulnerabilità che vengono sfruttate dagli attaccanti.
Nella terza parte verrà progettato e sviluppato un piccolissimo software
che adopereremo da esempio per studiare gli accorgimenti specifici, alcuni
5
A-PDF Split DEMO
ELENCO DELLE FIGURE
6
semplici ed altri più complicati, per assicurare un buon grado di sicurezza
senza influire in modo determinante sulla qualità del prodotto e del suo ’time
to market’.
Nell’ultimo capitolo vengono esposte alcune conclusioni a riguardo delle
problematiche analizzate e delle conoscenze acquisite con questo lavoro.
A-PDF Split DEMO
Capitolo 1
Concetti fondamentali
Ho avuto un’idea grandiosa, ma non mi è piaciuta
(Samuel Goldwyn)
Prima di iniziare a parlare di sicurezza nelle applicazioni web, vediamo
alcuni richiami e chiarimenti che possono risultare utili nella focalizzazione e
comprensione del problema che stiamo per affrontare.
Cerchiamo innanzitutto di capire da cosa è composta l’infrastruttura che
ospita i dati che tenteremo di proteggere cercando di dare alcune definizioni
per quanto riguarda l’architettura della rete, dei server e dei client, nonché
provando a chiarire il concetto di ’sicurezza informatica’.
Fissiamo fin da ora che l’applicazione web non è un unico blocco a se
stante, ma piuttosto un sistema complesso in cui un numero anche elevato di
componenti eterogenei interagiscono e collaborano al fine di fornire un servizio
o un prodotto agli utenti che ne fanno richiesta.
1.1
Le architetture distribuite
Solitamente si classifica come ’distribuitè tutte quelle architetture che non
rientrano nella classe di quelle centralizzate.
Come alternativa, per fare un po’ di chiarezza, le definiremo come quegli
impianti in cui sono presenti contemporaneamente:
1. più unità di tipo processore centrale
7
A-PDF Split DEMO
CAPITOLO 1. CONCETTI FONDAMENTALI
8
2. una ’computer network’
3. un software di sistema che gestisca l’impianto in modo da conferirgli le
seguenti proprietà:
• condivisione delle risorse
• apertura ad estensioni
• simultaneità operativa
• ampliabilità
• tolleranza ai guasti
• invisibilità
Sotto questa definizione rientrano alcuni sistemi anche molto diversi fra essi: sistemi di calcolo distribuito come Seti@Home e Prime95; sistemi paralleli
in rete; le reti peer-to-peer; sistemi client/server di cui ci stiamo interessando
in questa argomentazione.
1.1.1
La rete
La rete rappresenta il mezzo fondamentale in assenza del quale non potrebbe
esistere alcun sistema distribuito1 .
Le reti [5], o per esattezza, le computer network sono degli insiemi di
non trasparenti elaboratori autonomi, cioè tutti hanno le stesse funzioni e la
stessa libertà, interconnessi, vale a dire che tutti sono in grado di scambiarsi
messaggi secondo una stessa tecnologia. La trasparenza diversifica la rete da
un sistema distribuito. Quest’ultimo è composto da una rete in cui è presente
un software di gestione (sistema operativo o altra applicazione) che maschera
i singoli calcolatori. Per quanto riguarda invece l’omogeneità tecnologica della interconnessione, essa contraddistingue una rete da una inter-rete, cioè
quell’apparato costituito da reti tecnologicamente diverse che sono in grado
di colloquiare fra loro solo tramite dei gateway che effettuano la traduzione
dei messaggi provenienti da una rete e diretti verso l’altra secondo le caratteristiche proprie di ciascuna. Secondo le definizioni date Internet (con la
’i’ maiuscola) è una rete particolare: si tratta della inter-rete che a livello
mondiale può collegare tutte le reti.
1
secondo la definizione data in precedenza
A-PDF Split DEMO
CAPITOLO 1. CONCETTI FONDAMENTALI
9
Per poter ottenere tutto questo abbiamo bisogno sia di una portante
adeguata (filo rameico, tratta radio, fibra ottica) in base alle dimensioni ed
alle caratteristiche della net, sia di un sistema standard di comunicazione,
identificabile nei protocolli.
Figura 1.1: Rete locale con collegamento ad Internet
La figura1.1 ci mostra i collegamenti fisici che mettono in lan2 , e collegano
ad internet, alcuni host. Questi ultimi, collegati tramite hub e switch, comunicano inviandosi pacchetti informativi composti rispettando quanto stabilito
dai protocolli di comunicazione fissati.
Per la complessità di funzionamento delle moderne reti di calcolatori, il
software ha una enorme importanza e, come per la struttura fisica, è estremamente articolato e organizzato, in modo da facilitare la progettazione,
l’implementazione ed il testing.
Gli strati (layer) in cui esso è suddiviso, sono costruiti l’uno sopra il precente, a partire dallo strato fisico, per arrivare allo strato dell’applicazione.
Lo scopo di ogni livello è quello di creare una gerarchia di protocolli che offrano dei servizi allo strato superiore nascondendo i dettagli implementativi.
In particolare:
• lo strato n si una macchina comunica logicamente con lo strato n di
una macchina vicina ;
2
Local Area Network
A-PDF Split DEMO
CAPITOLO 1. CONCETTI FONDAMENTALI
10
• le regole e le convenzioni della suddetta comunicazione sono definite
protocollo di livello n ;
• le entità logiche che portano avanti una comunicazione, dette peer entity, di livello n, sfruttano i servizi offerti dalle peer entity dello strato
inferiore, secondo una determinata interfaccia.
La figura 1.2 mostra la logica della comunicazione fra due host chiarificando
il signicato e la locazione di livello, protocollo ed interfaccia.
La pila di livelli riportata in precedenza, con i relativi protocolli prende
il nome di ’architettura di retè. Le architetture che hanno avuto il maggior
successo si suddividono in due modelli: OSI/ISO e Internet (o TCP/IP).
Figura 1.2: Modello OSI / ISO
Il primo di questi (figura 1.2) è uno standard de iure3 , prodotto dall’ISO,
che si compone di sette strati caratterizzati da una forte suddivisione delle
funzioni.
Senza abbondare in dettagli possiamo dire che i primi quattro strati sono
orientati verso il mezzo fisico, cioè si occupano della trasmissione vera e propria, della gestione delle interferenze, della suddivisione e ricostruzione del
3
di diritto
A-PDF Split DEMO
CAPITOLO 1. CONCETTI FONDAMENTALI
11
carico informativo. Questi quattro strati, da soli, sono sufficienti per la gestione ed il controllo del canale. I tre strati più alti invece sono orientati agli
applicativi. Essi hanno il compito di ottimizzare l’uso della linea, controllare
la congestione, presentare il flusso dati all’ultimo livello in cui risiedono le
applicazini di rete (http, ftp, smtp...).
Il modello TCP/IP, sul quale si base la moderna Internet, è uno standard
de facto4 che nasce dalla rete militare ARPAnet. Conseguenze di queste sue
origini sono l’estrema robustezza verso gli attacchi ed i malfunzionamenti,
l’apertura a molti tipi di applicazioni di rete e la capacità di interagire con
altre tecnologie costruttive.
Gli strati in questo modello sono solo quattro: host-to-network raggruppa
i primi due livelli OSI e non ha funzioni definite; ip (il terzo livello ISO)
calcola il routing e gestisce le congestioni; trasporto mette in comunicazione
gli host tramite servizio con e senza connessione; applicazione, paragonabile
agli ultimi tre livelli iso.
1.1.2
L.A.M.P.
LAMP è l’acronimo che indica il Linux+Apache+MySql+PHP.
Con queste quattro lettere si intende una particolare combinazione si software di sistema che d’ora in poi, insieme alla rete sopra descritta sarà la
piattaforma di riferimento di questa tesi.
Questa combinazione è costituita da:
• linux, un sistema operativo multiprocess e multitask che oggigiorno
è ampiamente utilizzato nei server di dimensioni medie e piccole a
tecnologia IBM x86 ;
• un web server, Apache, che ha conquistato circa il 50% del mercato ;
• un rdbms, relational database management system, MySql ;
• il PHP, un linguaggio di scripting completamente orientato alla programmazione nel web.
La caratteristica saliente che accomuna tutti i componenti sta nel fatto che sono ’Open Source’, cioè freeware coperti da licenza GPL. Seppure
4
di fatto, in quanto ampiamente utilizzati
A-PDF Split DEMO
CAPITOLO 1. CONCETTI FONDAMENTALI
12
tutto potrebbe sembrare inefficiente e poco sicuro, in realtà, essendo progettati, sviluppati e testati da una comunità molto vasta garantiscono un livello
di efficienza, prestazioni e sicurezza elevato e certamente comparabile con i
prodotti commerciali più noti.
Linux
Linux è comparso nel 1991 come progetto personale di studio delle funzionalità di multiprogrammazione dei microprocessori i386 da parte di Linus
Torvalds, all’epoca studente presso l’Università di Helsinki, in Finlandia. Partendo dal sistema Minix, creò un kernel che rilasciò sotto licenza GNU-GPL,
che rappresenta la difesa ideale per un software di pubblico dominio.
Apache
Sviluppato dalla Apache Software Foundation, è oggigiorno il web server più
diffuso: stabile e sicuro, supporta l’integrazione con i principali rdbms e con
diversi linguaggi di programmazione, inoltre è facilmente espandibile grazie
alla gran quantità di moduli dalle funzioni più disparate.
Trascurando i moduli di autenticazione ed altre estensioni, il server web
è un programma che si occupa di ascoltare un canale di comunicazione per
intercettare una richiesta da servire secondo lo schema in figura 1.3.
Figura 1.3: Semplice schematizzazione dell’interazione client - web server
Il client, utilizzando un browser, lancia una messaggio di richiesta http,
contenente la URL5 , attraverso il collegamento di rete al web server. Questo,
5
Uniform Resource Location
A-PDF Split DEMO
CAPITOLO 1. CONCETTI FONDAMENTALI
13
catturata la richiesta, risponde, sempre attraverso il protocollo http, con una
pagina html con il contenuto informativo desiderato dal client.
MySQL
Le basi di dati (cit. [6]) sono dei contenitori atti a immagazzinare dati,
strutturati o meno. In effetti una base di dati è definita da un insieme di regole
che specificano il modo in cui lo stream informativo debba essere registrato.
MySQL è un RDBMS, cioè un sistema di gestione di basi di dati relazionali. Esso si occupa, da un lato di gestire la struttura e la coerenza dei file
su disco, e dall’altro si rispondere alle interrogazioni che l’utente o un’applicazione gli pongono secondo un linguaggio di interrogazione standard (SQL,
Standard Query Language.
MySQL è in grado di gestire database in diversi formati. I principali sono
sono:
• myISAM, implementazione dei B-alberi, è il formato nativo ed include
molti tool di ottimizzazione e backup ;
• innoDB, supporta le transazioni e le foreign keys ;
• BerkeleyDB, con supporto per le transazioni ma poco flessibilie con
basse prestazini.
PHP
PHP è l’acronimo ricorsivo di Hypertext Preprocessor, attualmente è uno dei
linguaggi web più diffusi su internet che permette di creare da semplici script
fino ad interi portali dinamici. PHP è un linguaggio interpretato, nato da
un progetto della Apache Software Foundation, l’interprete che ne costituisce
il cuore è proprietà della Zend inc. (www.zend.com) che ne distribuisce i
sorgenti gratuitamente.
Esso consente di realizzare velocemente pagine a continuti dinamici, grazie
al supporto nativo con i singoli rdbms ed anche alla numerosità delle funzioni
built-in e delle librerie reperibili in modo gratuito.
La figura 1.4 mostra i passaggi seguiti dal server per rispondere alla
richiesta di un client.
All’arrivo della richiesta (1) il server esegue un controllo sull’URL e decide
se prelevare una pagina HTML statica (2) oppure se eseguire uno script per la
A-PDF Split DEMO
CAPITOLO 1. CONCETTI FONDAMENTALI
Figura 1.4: Flusso dati di un web server con php
14
A-PDF Split DEMO
CAPITOLO 1. CONCETTI FONDAMENTALI
15
generazione di una pagina dinamica (3). In questa ultima eventualità il codice
viene passato al PHP preprocessor che lo esegue, con eventuali richieste al
server SQL (5, 6, 7) ed ai file systems, e genera in output una pagina statica
(8). La pagina finale (prelevata dal file system o generata dallo script) viene
restituita in risposta al client (9).
Il successo di questo linguaggio deriva a pari merito da tre fattori:
• Efficienza: punto di forza è proprio la velocità dell’interprete nella valutazione degli script, la Zend fornisce a pagamento un ’pre-interpretè
in grado di migliorare ulteriormente questa caratteristica.
• Portabilità: utilizzando piccoli accorgimenti PHP è in grado di funzionare su diverse piattaforme (Windows32, Unix, Mac OS X, AS/400...)
ed è in grado di appoggiarsi indifferentemente a diversi web server
(Apache, Microsoft IIS, Xitami, OpenHTTPd, ecc...) sfruttando l’interfaccia CGI (Common Gateway Inferface).
• Accesso a basso livello: permette di accedere a basso livello all’architettura web sottostante, come per esempio la possibilità di modificare
manualmente gli header del protocollo HTTP, accesso alle primitive
di sistema, funzioni per gestire socket, ecc...
1.2
Le applicazioni Web
A partire dal primo Congresso Web tenutosi a Ginevra nel 1994 è iniziata
ad affermarsi l’esigenza di rendere il web dinamico. L’HTML di per se è
statico, permette al massimo di inserire in una pagina un’immagine, una
colonna sonora oppure uno spezzone video. L’HTML non è un linguaggio
di programmazione ma solo di formattazione dei contenuti, permettendo di
controllare come un testo comparirà nella finestra del browser.
Brevemente una ’applicazione web’ è un software, eseguito dall’application
server di un web server, che produce dinamicamente pagine html secondo le
richieste degli utenti e degli altri sistemi della rete.
Le funzioni svolte da questo tipo di software possono andare dalla semplice ricerca e fruizione di un file in una directory a delle applicazioni estremamente sofisticate che eseguono in tempo reale vendite, tenuta del magazzino,
registrazione di dati finanziari.
A-PDF Split DEMO
CAPITOLO 1. CONCETTI FONDAMENTALI
16
Anche le tecnologie che sono alle spalle di questi software sono estremamente varie: dal semplice script fino ad un complicato programma in linguaggio di alto livello che interagisce con diverse risorse dati localizzate su sistemi
ed in modi diversi.
A causa di tali caratteristiche le applicazioni sono estremamente disomogenee, e non permettono alcuna tassonomia o ricerca. L’unica analisi che può
essere realizzata è uno studio del tutto generale a riguardo della struttura
interna del software.
Figura 1.5: Applicazione web three-tier
Cosı̀ come è mostrato in figura 1.5 l’applicazione può essere scomposta in
tre layer: di presentazione, logico e dati.
Il primo stato, più esterno, gestito dal web server, si occupa della presentazione dei dati, strutturandoli e formattandoli in una GUI6 tramite un
linguaggio interpretabile dal browser (o da un generico client), tipicamente
html oppure xml.
Il layer logico è il vero nucleo dell’applicazione. In esso si concentra l’implementazione degli algoritmi, sia quelli funzionali all’offerta del servizio, sia
quelli accessori, come per esempio il controllo di sicurezza. Capita, però, che
questo strato sia talmente sottile da poterlo inglobare nel presentation layer oppure, al contrario, sia cosı̀ complesso da dover essere diviso in diverse
sezioni cooperanti fra loro che si occupano di compiti molto specifici.
L’ultimo strato, non meno importante, svolge la funzione di storing dei
dati: database, file e archivi.
6
Graphic User Interface
A-PDF Split DEMO
CAPITOLO 1. CONCETTI FONDAMENTALI
1.3
17
Cosa intendiamo per sicurezza
La sicurezza informatica è la tutela del sistema informativo dalla violazione
da parte di persone non autorizzate al fine di garantire confidenzialità, autenticità, integrità e disponibilità dei dati.
Sebbene questa definizione sia chiara e concisa, in realtà, la sicurezza
con è una caratteristica assoluta ma una misura che si tenta si massimizzare
valutando attentamente l’equilibrio fra costo del rischio e costo della difesa.
Bisogna rendersi conto che, come insegna l’ingegneria del software ormai
da qualche anno, un programma ‘zero risk’ è, oltre che irrealizzabile, inutile,
in quanto implica un costo di progettazione, sviluppo e testing decisamente
maggiore del costo, inteso come perdita di profitto o di immagine, che si
avrebbe nel caso di intrusione o manipolazione del sistema. Si segue, in
definitiva, il ”principio del minimo rischio” (o del minimo costo, se visto dal
lato manageriale).
1.3.1
Vulnerabilità, minaccia e rischio
Si è detto che un sistema può incorrere in dei rischi, può essere affetto da vulnerabilità, può essere minacciato, senza chiarire il significato con il quale stiamo adoperando ciascun termine. Il significato specifico non è molto diverso
dal quello che comunemente assegnamo a tali parole.
Una vulnerabilità, o falla, come si sente dire in spesso, è la caratteristica di un componente, o di un sistema nella sua interezza, per cui risulta
suscettibile a particolari situazioni che portano al guasto, spesso improvviso,
del componente stesso o di un altro che si trova rapporto collaborativo con
quello fallato.
La minaccia è la causa che scatena il guasto di cui si è appena detto.
Essa deriva marginalmente da problemi di implementazione, specialmente se
cooperativa o in team, ed in larga misura da comportamenti anomali degli
utenti. Fra questi ultimi dobbiamo fare distinzione fra: gli hacker, beta tester
esperti della materia che tentano di stressare il sistema al fine di migliorarlo
oppure di aumentare il loro grado di conoscenza; i cracker, che sfruttano le
stesse tecniche e gli stessi strumenti degli hacker ma con fine personale spesso
illegale fra cui non manca la frode, lo spionaggio industriale, la concussione; i
phraker, raramente esperti, utilizzano tool freeware e tutorial reperibili nella
rete per divertimento personale.
A-PDF Split DEMO
CAPITOLO 1. CONCETTI FONDAMENTALI
18
Il rischio è la probabilità che una falla sia incontrata (o scoperta) da
una minaccia, associata all’intenzione di sfruttarla per trarne un vantaggio.
Possiamo ipotizzare che maggiore sarà il vantaggio, maggiori saranno gli sforzi
per trovare le vulnerabilità, o meglio, il rischio è tanto più elevato quanto più
hanno valore i dati che tentiamo di proteggere.
Sottolineiamo, un ultima volta, che non stiamo parlando di caratteristiche
assolute (booleane) ma di una misura relativa, di un grado di proprietà.
La relazione fra queste parole è decisamente più chiara quando la poniamo
in formato (ingegneristico) di equazione:
vulnerabilità + minaccia = rischio
Un rischio si riscontra solo nel caso in cui il sistema, affetto da punti di
vulnerabilità, diventa oggetto di interesse di una minaccia. Inoltre, il livello
di rischio è proporzionale al numero di falle ed al numero di attaccanti.
1.3.2
Le sicurezza su più livelli
Come detto in principio e ribadito numerose volte, tentiamo di proteggere una
mole di informazioni a gestite da un sistema, accessibili solo ed esclusivamente
da un gruppo definito e limitato di utenti, e posizionati in una architettura
aperta (ed esposta) all’intero pianeta.
Dovendo scomporre il sistema in un albero funzionale (l’abbiamo visto
nei paragrafi precedenti), non possiamo applicare una politica di sicurezza
generale concentrata in un’unico punto ma siamo costretti a progettare ed
implementare un checkpoint ad-hoc per ogni sottosistema, fino ad arrivare
ai nodi estremi, cioè i singoli componenti. Seguendo il percorso temporale
degli ultimi tre decenni, applicheremo un controllo sulla rete, poi sul sistema
operativo e sul web server, alla fine implementeremo dei check di sicurezza
sulla applicazione web. Ovviamente ci sono casi in cui le misure di sicurezza
influenzano contemporaneamente più componenti, come ad es. i firewall che
eseguono controlli sia sull’host/ip di destinazione o sorgente e sull’applicazioni
che li genera o riceve.
Stiamo tralasciando la sicurezza dell’host client ma, posto che questa tesi
non concerne questo argomento, supponiamo che essa sia banale e limitata
all’aggiornamento dei client ed all’installazione di programmi freeware (non
meno potenti di quelli commerciali) che in real-time mantengano una politica
A-PDF Split DEMO
CAPITOLO 1. CONCETTI FONDAMENTALI
19
minima sul PC dell’utente: firewall (sia traffico in entrata ché in uscita), antivirus (per backdoor e keylogger), anti-scripting (controllo di codice javascipt
malizioso), anti-spam (per email in html contenente javascript).
Ovviamente tralasciamo anche un fattore estremamente importante: quello umano. Diamo per scontato, insomma, che il generico utente (e magari anche l’amministratore e lo sviluppatore/tester) non tenga username/password
memorizzate in auto-login o stampate a caratteri ben leggibili e incollati dove
un visitatore qualsiasi le possa vedere, anche solo per caso. E neppure che
risponda a chiunque gli chieda dei parametri di autenticazione (ad es. per
email falsificata, alcuni siti web ne permettono l’invio in modo facilissimo ed
indiscriminato) senza eseguire un controllo (ad es. telefonata di conferma).
A livello di rete
Già da questo livello è possibile portare attacchi al programma. Ad es. inviando traffico fasullo forgiato ad-hoc per mandare in panne un router oppure
un server DNS.
Sebbene i puristi ricorrono ancora a diverse ore davanti ad un terminale
telnet, per controllare le porte note in cerca di qualche debolezza di una
macchina, ed impieghino alcune settimane per scrivere lo script dell’attacco,
sono gratuiti e numerosi i port-scanner e si riescono a reperire dei tool per il
testing di vulnerabilità note.
La china di figura 1.6 mostra la protezione standard che si applica ad
alla lan aziendale per prevenire attacchi dall’esterno. Questa potrebbe essere
anche una ottima struttura difensiva per un host/rete client.
Il traffico in entrata/uscita passa attraverso un unico nodo protetto da
un proxy e da un firewall (essendo su LAMP si possono adoperare Squid ed
IPtables). Sulla stessa piattaforma potrebbero essere presenti i server (web,
file, printer). Il firewall si occupa di filtrare i pacchetti applicando regole
di sicurezza ai livelli non superiori al quarto: ad esempio chiudendo tutte
le porte, ad esclusione della 80, e canalizzando (tunneling) le porte rilevanti
(ftp, pop e imap, vnc, x-server...) sulla porta SSH. Il proxy si occupa sia
dell’applicazione delle regole ai livelli più alti (ad es. controllo del contenuto)
sia di un eventuale mascheramento dell’ip del client (natting e/o semplice
caching delle risorse richieste).
Questa topologia (con controllo centralizzato in uno o pochi nodi) in grado
di segmentare logicamente la rete separando i sistemi interni (considerati
A-PDF Split DEMO
CAPITOLO 1. CONCETTI FONDAMENTALI
20
Figura 1.6: Rappresentazione estesa del client
di fiducia) da quelli esterni accessibili al pubblico che, in quanto privi di
tale fiducia, devono rimanere isolati, prende il nome di firewalling della zona
perimetrale o DMZ, De-Militarized Zone. Essa è una soluzione valida (e poco
dispendiosa) per tutte le reti di medie/grosse dimensioni oppure per le reti in
cui l’accesso ad internet è effettuato da un solo PC con condivisione/bridging
della connessione.
Naturalmente l’esistenza di una DMZ non rappresenta da sola una garanzia
sufficiente ma deve essere accompagnata dalla presenza di adeguati dispositivi
di controllo degli accessi (router e firewall) in modo tale da: bloccare tutto
il traffico UDP e TCP non strettamente necessario; bloccare tutte le connessioni TCP che traggono origine dallo stesso server Web; bloccare il traffico
tra il server Web e la rete interna.
Oltre alla parte di bassissimo livello è il caso di fare un remark a riguardo
dei protocolli di livello applicativo ed in particolare di HyperText Transfert
Protocol.
HTTP/0.9, che potremmo definire ‘versione originale’, è stato concepito
dal CERN nel 1990 con lo scopo di creare un area dove inserire/duplicare/eliminare documenti di qualunque tipo (in genere testo piatto o formattato
ed un set minimo di feature multimediali). Esso non prevedeva (se non in
modo primordiale) il surfing, che è alla base del successo del Web.
A-PDF Split DEMO
CAPITOLO 1. CONCETTI FONDAMENTALI
21
HTTP odierno (cit. [18]), versione 1.1, è il risultato di un grosso lavoro di
adattamento (iniziato con la versione 1.0 e ancora non concluso pienamente)
per deviare HTTP/0.9 verso una piattaforma dove potessero essere eseguiti
programmi complessi che il mercato chiedeva con sempre maggiore insistenza. Questo processo è sfociato in un prodotto decisamente lacunoso in parte
rimediato da patch e accorgimenti (alle volte strutturali).
A livello di sistema operativo
In linea generale il percorso che un aggressore tenta di seguire nell’attacco di
un sistema può essere riassunto nel modo seguente:
1. accesso al sistema attraverso l’esecuzione di exploit, lo sfruttamento
di condizioni di buffer overflow in script e programmi, la cattura o
l’intercettazione del file delle password, gli attacchi a forza bruta;
2. scalata dei privilegi e/o impersonificazione degli utenti con privilegi amministrativi attraverso il crack delle password e/o l’esecuzione di exploit
successivi;
3. occultamento delle tracce tramite la cancellazione dei logs, l’uso di
rootkits e lo sfruttamento di particolari caratteristiche del sistema operativo;
4. installazione di backdoors cioè di programmi nascosti che aprono all’aggressore delle porte senza restrizioni con la possibilità di controllare il
sistema in qualsiasi momento;
Il sistema operativo può avere un impatto significativo nella predisposizione e nel mantenimento dei giusti livelli di sicurezza sotto i seguenti
profili:
1. assenza di vulnerabilità note nei confronti di tipologie conosciute di
attacco;
2. capacità di limitare determinati tipi di attività soltanto ad alcuni utenti;
3. abilità nel rimuovere e disabilitare servizi e risorse non necessari;
4. abilità nel controllare l’uso e l’accesso alle varie risorse e nel registrare
la varie attività degli utenti;
5. facilità di gestione ma non a discapito della sicurezza;
A-PDF Split DEMO
CAPITOLO 1. CONCETTI FONDAMENTALI
22
A livello di applicazione
Abbiamo ben definito (vedi figure 1.4 e 1.6) l’ambiente e l’infrastruttura sulla
quale seguiremo il nostro studio e la nostra discussione. Adesso che abbiamo
posto in sicurezza i livelli più bassi del sistema dobbiamo concentrarci sugli
strati alti, che (per il punto di vista di questa tesi) sono il punto di accesso
centrale di tutto il sistema.
Nei prossimi capitoli si illustreranno in modo teorico ed alle volte pratico
le tecniche di attacco, spiegando in quali punti si concentrano le vulnerabilità.
In eseguito verrà progettata e realizzata una applicazione cercando quel punto
di equilibrio fra costo e beneficio al quale il cliente fa riferimento.
1.3.3
Costo dei rischio e costo della sicurezza
A fronte della possibilità di proteggere i nostri dati, cerchiamo di capire,
sotto il punto di vista manageriale, quale possa essere il grado di sicurezza
che il progetto richiede: ipotizziamo a tal fine che il livello di sicurezza da
preventivare dipenda solo dal valore dei dati, trascurando altri fattori di per sé
minori. Teniamo in considerazione inoltre che un eccessivo livello di sicurezza
rende il prodotto finale poco usabile: immaginiamo il caso in cui una login
richieda tre password, oppure l’inserimento di una codice di controllo ogni
quarto d’ora.
Diamo per scontate le basilari regole dell’ingegneria del software per cui
apportare delle modifiche al progetto in fase di sviluppo implica un costo
che non è trascurabile. Inoltre il processo di progettazione dell’applicazione
è ciclico.
Affrontando un progetto per la realizzazione di un servizio basato su tecnologia Internet, sono di primaria importanza l’analisi della riservatezza delle
informazioni trattate e l’identificazione di quale sia il corretto livello di sicurezza da realizzare. Chiaramente, il costo dell’infrastruttura di sicurezza
è intimamente legato al livello di affidabilità che si vuole raggiungere; dare
specifiche di tutela troppo stringenti se comparate alla riservatezza dei dati
contenuti nel sistema può comportare uno spreco di risorse superiore al danno potenziale del furto delle informazioni stesse. E’ quindi sempre necessario
relazionare lo sforzo economico previsto con il potenziale danno.
A-PDF Split DEMO
Capitolo 2
Tecniche di attacco
La scienza è sempre imperfetta. Ogni volta che risolve
un problema ne crea almeno dieci nuovi
(George Bernard Shaw)
Un ispezione sommaria del codice, fatta da un programmatore anche esperto, non può rilevare i problemi e le falle di sicurezza dell’applicazione. Da
una parte infatti, il testing manuale non può contemplare tutte le sequenze di input, e soprattutto non si pensa mai ad eseguire delle manipolazioni
dell’applicazione per testarne la risposta. D’altro canto, i tool di testing automatizzati, non essendo progettati per una applicazione specifica, ma per
una classe poco disomogenea di programmi, non possono assicurarci nulla.
Quindi per capire come bloccare un attacco bisogna preventivamente
capire in cosa consiste questo attacco, quali vulnerabilità sfrutta e in quali
componenti sono situate tali falle.
2.1
Information gathering - Messaggi ed errori
Non si tratta di un vero e proprio attacco, in quanto cerca di reperire qualunque
informazione tecnica su una applicazione. Ha una pericolosità bassissima ma
è il primo passo verso la maggioranza degli attacchi seri.
23
A-PDF Split DEMO
Capitolo 3
Tecniche specifiche per la difesa
Ciò che dobbiamo imparare lo impariamo facendo
(Aristotele)
Vedremo in questo capitolo le tecniche di difesa, alcune basilari altre avanzate, messe in atto dagli sviluppatori e dai progettisti per mitigare (o bloccare)
i rischi da attacco digitale.
Verrà progettato un forum radicalmente diverso da quello usato negli esempi del capitolo precedente: esso deve consentire lo scambio di file e messaggi altamente riservati fra i componenti di alcuni gruppi di lavoro fra i
quali dirigenti del comparto R&D, il nucleo di valutazione qualità, il comitato decisionale. A tal fine eseguiremo un attento studio dell’efficienza delle
diverse possibilità ed applicheremo, in ogni componente, la migliore, oppure
le due/tre migliori se ne riscontreremo la necessità.
3.1
INFN Forum
Il forum INFN è uno strumento messo a disposizione per due finalità principali: dare supporto agli utenti delle applicazioni web sviluppate dalla Divisione Gestione Dati Ricerca e dare ai gruppi di lavoro un punto di riferimento
dove poter scambiare messaggi e file.
Attualmente è realizzato con phpBB, al quale sono state apportate delle
36
A-PDF Split DEMO
Capitolo 4
Conclusioni
Quanto manca alla vetta ?
Tu sali e non pensarci !
( F. W. Nietzsche )
Fino a poco tempo fa la sicurezza informatica era considerata ‘la figlia
della serva’, perché non c’era ancora la percezione del valore dell’informazione
e della sua vulnerabilità.
Oggi, quantità sempre maggiori di dati ed informazioni viaggiano attraverso ‘il sistema nervoso digitale’ (B. Gates, Giugno 1999). Spesso, tali dati
non sono interessanti solo ed esclusivamente per i loro proprietari. Soltanto dopo i primi problemi seri, si cominciano a considerare gli investimenti
per la sicurezza come soldi spesi bene, anche perché in numerose realtà, la
corruzione o il furto di un database potrebbero determinare il crollo totale
dell’azienda.
Volendo riassumere questo lavoro è possibile dire che se si vuole rendere
un server sicuro non basta affidarsi a degli esperti amministratori di sistema
e di rete, cosı̀ come non è sufficiente nemmeno installare una suite software
di protezione integrata per risolvere il problema delle intrusioni e del furto
telematico.
Abbiamo visto come l’applicazione non possa essere considerata un blocco
nel quale entrano ed escono dati, ma piuttosto debba essere considerata un
insieme di sistemi ‘vivi’ ed in evoluzione che cooperano fra loro, alle volte
52
A-PDF Split DEMO
APPENDICE C. AUTENTICAZIONE
70
022 require valid-user
Secondo tali direttive, il server Apache si collega automaticamente a server MySQL con il nome utente e la password specificati alle righe sette e otto.
Viene adoperata la tabella ’amministratore’ nel database ’forum’ per controllare la presenza dell’utente, eseguendo un confronto fra il nome utente ed il
campo ’uname’ e fra la password ed il campo ’pword’.
Per quanto riguarda la sezione utenti, viene utilizzata la stessa struttura,
ma cambia la tabella degli utenti ed il nome dei campi.
Da notare che questo strumento di autenticazione non necessita di salvare il nome utente e la password nel client quindi non è necessario prevedere
la funzionalità di log-out, con la quale si invalidano i dati di autenticazione
(normalmente posti in cookie). Al contrario, l’applicazione non ha memoria di una precedente autenticazione ed è necessario autenticarsi nuovamente
quando vi si accede sopo aver chiuso il browser.
L’autenticazione sella sezione di amministrazione avanzata, creata con
phpMyAdmin, è doppia:
• la prima delle due è richiesta per avere accesso nell’applicazione ;
• la seconda per potersi collegare al db.
Par avere accesso, quindi, occorre conoscere sia i parametri di applicazione,
cioè quelli contrnuti nella tabella ’amministratore’ di cui prima, ed i parametri
di utente MySQL.
A-PDF Split DEMO
Ringraziamenti
Quanto più ci innalziamo, tanto più piccoli sembriamo
a quelli che non possono volare
(F. Nietzsche)
Devo ringraziare un numero cosı̀ grande di persone che mi dimenticherò
certamente di qualcuno di loro...
Chi mi è stato vicino prima, durante e dopo la stesura di questo documento.
Coloro che mi hanno insegnato tutto quello che non è scritto sui manuali.
Non per ultimi chi, amici e non, mi hanno dato almeno un suggerimento
o una spinta a completa.
Un grazie particolare alla mia famiglia, a Marina e Fabrizio per avermi
fornito i mezzi.
La grandezza dell’uomo si misura in base a quel che cerca
e all’insistenza con cui egli resta alla ricerca
(Heidegger)
71
A-PDF Split DEMO
Bibliografia
Bibliografia
[1] Mark Curphey et al. A guide to build secure web applications . Capitoli
6 e 11. O.W.A.S.P. 2005.
[2] Ilias Bartolini. PHP e sicurezza Web: consigli per non fare danni nel
Web con PHP . Slides dell’intervento alla conferenza PHP-Day-2004.
[3] P. Atzeni et al. Basi di dati: concetti, linguaggi e architetture. McGrawHill, seconda edizione 1999
[4] Chris Shiflett. PHP Security O’Reilly Open Source Convention Portland,
Oregon, USA 26 Jul 2004
[5] Marco Cesati. Appunti del corso di Reti di Calcolatori Anno Accademico
2003/2004
[6] Raghu Ramakrishnan e Johannes Gehrke. Database Management
Systems, 2nd Edition. McGraw Hill, 2000 (ISBN 0-07-232206-3).
[7] Steven Cook. A Web Developer’s guide to Cross-Site scripting. SANS, 11
Gennaio 2003.
[8] Mike Shema. Hack Notes: Web Security portable reference. McGraw Hill.
[9] Johan Brissaud. Programming:
The Heart of Web
http://www.securitydocs.com/library/2834 5-Gennaio-2005
Security.
[10] Tricia Lupien. Programmer’s Ultimate Security DeskRef:
Ottobre 2004
PHP 12
[11] Watching
the
Watchers:
http://johnny.ihackstuff.com
Hacking
72
with
Google.
2002,
A-PDF Split DEMO
BIBLIOGRAFIA
[12] Sebastian
Wolfgarten.
Watch
out,
Google.
www.wolfgarten.com/downloads/Watch out google.pdf
73
2003,
Riferimenti
[13] http://www.php.net/
[14] http://talks.php.net/show/web-app-security/
[15] http://talks.php.net/show/php-under-attack/
[16] PHP Security - www.php.net/manual/en/security.php
[17] Secure Programming in PHP - www.zend.com/zend/art/art-oertli.php
[18] www.w3.org/Protocols/rfc2616/rfc2616.html
[19] www.impervia.com (diverso materiale, in particolare white papers)
[20] http://www.hackingspirits.com/eth-hac/papers/Demystifying
[21] http://www.foundstone.com/resources/whitepapers/wp sitedigger.pdf