Sicurezza Informatica nello sviluppo di applicazioni in - INFN-LNF
Transcript
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