UNIVERSITÀ DI CATANIA Facoltà di Ingegneria Corso di laurea Specialistica in Ingegneria Informatica. Simona Ullo

Transcript

1 UNIVERSITÀ DI CATANIA Facoltà di Ingegneria Corso di laurea Specialistica in Ingegneria Informatica Simona Ullo ATTACCHI ALLE APPLICAZIONI WEB: SQL INJECTION E CROSS SITE SCRIPTING (XSS) Tesina di Sicurezza nei Sistemi Informativi Docente: Prof. O. Tomarchio Anno Accademico 2007/2008

2 Indice 1 Introduzione III 1.1 La (in)sicurezza delle applicazioni web III 1.2 Le vulnerabilità delle applicazioni Web V 2 SQL Injection Introduzione I bersagli della SQL injection Test di vulnerabilità alla SQL injection Tecniche di SQL injection Filtraggio inadeguato dei dati in ingresso Assenza di un controllo dei tipi Messaggi di errore ODBC Vulnerabilità dei server SQL Tecniche di protezione da attacchi di SQL injection Alcuni strumenti utili Cross Site Scripting Introduzione Tipologie di Cross-Site Scripting Attacchi XSS non persistenti I

3 3.2.2 Attacchi XSS persistenti Attacchi XSS DOM-based Tecniche di Cross-Site Scripting Accesso alla cronologia Accesso alla Intranet Tecniche di protezione da attacchi di Cross-Site Scripting Filtraggio delle informazioni Sicurezza del browser web Paros: un esempio di pen tester Introduzione Installazione e configurazione Caratteristiche generali Scansione delle vulnerabilità Un esempio di scansione Bibliografia 55 Indice 56 II

4 Capitolo 1 Introduzione 1.1 La (in)sicurezza delle applicazioni web Il World Wide Web è stato caratterizzato da un imponente crescita negli ultimi anni. Dai singoli individui alle grandi aziende e ai governi, tutti ormai ne fanno infatti un largo utilizzo, grazie alla sua efficacia comunicativa. Tuttavia, l aspetto della sicurezza nelle applicazioni web spesso non è ritenuto predominante e viene sottovalutato per contenere i costi di implementazione o, talvolta, per semplice ignoranza. Il risultato è che, attualmente, la maggioranza delle applicazioni web è lungi dall essere sicura. Il primo passo per produrre un software sicuro consiste, certamente, nel curare gli aspetti della sicurezza già a partire dalla sua implementazione. In tal modo, è possibile affrontare il problema alla radice e con dei costi minori rispetto a quelli che si affronterebbero successivamente ad un attacco andato a buon fine. Come si suol dire: prevenire è meglio che curare. In un ambiente di così vasta diffusione come il web, sottovalutare l aspetto della sicurezza di un applicazione può comportare seri danni, soprattutto per quegli enti che gestiscono informazioni critiche, delle quali è necessario garantire confidenzialità ed integrità. III

5 Ma cosa si intende con il termine applicazione web? Un applicazione web può essere considerata come una qualsiasi applicazione eseguita mediante un browser web, al fine di instaurare una comunicazione con un web server. Agli albori della storia di Internet, l unico obiettivo del World Wide Web era quello di fornire pagine web statiche agli utenti. La comunicazione avveniva in un unica direzione: dal server al browser. Le uniche vulnerabilità erano quindi insite nello stesso server web, ma l eventuale accesso non autorizzato non metteva a rischio alcuna informazione critica, poichè tutte le informazioni possedute dal server erano già di pubblico dominio. Attualmente la situazione è radicalmente cambiata. La maggior parte dei contenuti del web sono infatti applicazioni, che consentono una comunicazione bidirezionale tra server e browser. Diventano importanti, quindi, il controllo degli accessi degli utenti, la sicurezza delle transazioni di commercio elettronico, l accesso autorizzato ad informazioni confidenziali. Ciascun contenuto, al giorno d oggi, è totalmente personalizzato rispetto all identità dell utente connesso ed è dunque di carattere dinamico. Ecco quindi che vengono fuori le svariate vulnerabilità delle applicazioni, ed ecco che la sicurezza diventa un fattore determinante: chi utilizzerebbe un applicazione web se sapesse che le informazioni private inserite potrebbero essere accedute da terze parti non autorizzate? Dal momento che ciascuna applicazione web presenta le proprie vulnerabilità, renderle note costituisce un arma a doppio taglio. Se da una parte l analisi di tali vulnerabilità può infatti portare i progettisti a consolidare il sistema rispetto ad eventuali attacchi esterni, dall altra essa può facilitare il compito degli attaccanti nel portare a termine le loro incursioni con successo. Ogni attacco è infatti ideato in modo tale da sfruttare tali vulnerabilità, al fine di guadagnare un accesso non IV

6 autorizzato alle informazioni o al sistema stesso. Di seguito verranno esaminate, quindi, le principali vulnerabilità delle applicazioni web ed i relativi attacchi a cui possono essere esposte, allo scopo di accedere ad informazioni riservate, di minare la loro integrità o di guadagnare il controllo vero e proprio del web server. 1.2 Le vulnerabilità delle applicazioni Web Navigando in rete ci si imbatte molto spesso in siti nei quali ricorre la dicitura Questo sito è assolutamente sicuro. Le informazioni private sono protette mediante la tecnologia SSL (Secure Socket Layer). In realtà, la maggioranza delle applicazioni web non è affatto assolutamente sicura e le sue vulnerabilità non hanno niente a che vedere con l utilizzo di canali sicuri SSL. Ciò non vuol dire che SSL sia inutile, ma semplicemente che esistono altre debolezze sfruttabili per attacchi alle applicazioni web, le quali possono essere ricondotte alle seguenti categorie: Broken authentication: debolezze nel sistema di autenticazione degli utenti; l attaccante può indovinare facilmente le password, effettuare un attacco a forza bruta o aggirare totalmente l operazione di login. Broken access control: debolezze nel sistema di controllo degli accessi; l attaccante può accedere ai dati sensibili degli utenti e guadagnare in maniera illecita permessi per effettuare azioni privilegiate. Information leakage: l attaccante può entrare in possesso di particolari informazioni sensibili, rivelate erroneamente dall applicazione durante la vi- V

7 sualizzazione, ad esempio, di commenti dello sviluppatore o di messaggi di errore. SQL injection: l attaccante può inserire appositi input, ad esempio attraverso form, per interferire con l accesso dell applicazione ai database, riuscendo in tal modo a reperire le informazioni in essi contenute, modificarle o eseguire comandi sul server contenente il database stesso. Cross-Site Scripting: consente all attaccante di prendere di mira determinati utenti dell applicazione al fine di accedere ai loro dati, effettuare azioni per loro conto o eseguire altri attacchi contro di essi. Secondo test effettuati sulle più comuni applicazioni web [7], il 36% di esse è vulnerabile alla SQL injection, mentre ben il 91% può essere facilmente attaccato sfruttando il cross-site scripting. Tali vulnerabilità verranno trattate in dettaglio nei capitoli successivi. Il problema fondamentale dal quale scaturisce l insicurezza delle applicazioni web sta nella possibilità dell utente, che si trova al di fuori del raggio d azione dell applicazione stessa, di inserire informazioni totalmente arbitrarie che, se non opportunamente filtrate, possono costituire codice malevolo, utilizzabile per portare a termine un attacco. Il progettista dell applicazione web deve quindi supporre che qualsiasi informazione inserita possa costituire una potenziale minaccia, avente come obiettivo l accesso a dati o a funzionalità del sistema riservati. Le modalità mediante le quali è possibile portare a termine un attacco sfruttando questa vulnerabilità, sono svariate: l utente può interferire in un qualsiasi flusso di dati scambiati tra client e server: dai parametri nell URL ai cookies di sessione, dalle query SQL ai form HTML. VI

8 Ecco spiegata la ragione per cui introdurre la tecnologia SSL per le transazioni web non è sufficiente a garantire la sicurezza delle informazioni. SSL fornisce infatti gli strumenti per far viaggiare in maniera sicura i messaggi scambiati tra client e server, in modo che non possano essere minate l integrità e la confidenzialità degli stessi e garantendone l autenticazione. Tuttavia, nulla vieta che le informazioni trasmesse dal client siano in realtà codice malevolo. In tal caso, tutto ciò che sarà in grado di fare SSL sarà semplicemente offrire all utente un canale sicuro per far viaggiare il proprio attacco. Ciò che ci si propone in questo lavoro è, quindi, fornire una descrizione dei possibili attacchi alle applicazioni web, focalizzando l attenzione su due tra i più diffusi: la SQL injection e il Cross-Site Scripting. Verranno inoltre analizzate alcune delle contromisure utili a fronteggiare tali tipologie di attacchi, al fine di conferire alle proprie applicazioni web una maggiore sicurezza. VII

9 Capitolo 2 SQL Injection 2.1 Introduzione L attacco denominato SQL injection costituisce uno degli svariati attacchi alle applicazioni web che rientrano nella categoria della cosiddetta code injection. L argomento della code injection è molto vasto e riguarda una serie di linguaggi ed ambienti differenti il cui filo conduttore è l inserimento di codice malevolo in un applicazione web, avente l obiettivo di inteferire con il suo funzionamento, al fine di ottenere l accesso non autorizzato ad informazioni riservate o l esecuzione di comandi illeciti. La code injection fa riferimento, in particolare, alla categoria dei linguaggi interpretati, ovvero quei linguaggi le cui istruzioni vengono tradotte ed eseguite a tempo di esecuzione. La maggior parte dei linguaggi impiegati nelle applicazioni web appartiene a tale categoria, per cui risulta vulnerabile ad attacchi di code injection. Tale debolezza è dovuta al fatto che, nei linguaggi interpretati dedicati al web, sono le informazioni fornite dall utente a determinare le azioni da compiere, per cui il codice elaborato dall interprete risulterà un miscuglio tra le istruzioni scritte dal programmatore ed i dati inseriti dall utente stesso. Un attaccante può quindi inserire informazioni che esulano dal contesto dei 1

10 CAPITOLO 2. SQL INJECTION dati richiesti, ma che sintatticamente vengono valutate dall interprete come vere e proprie istruzioni del linguaggio in questione. Il risultato è che esse vengono eseguite indistintamente insieme al codice scritto in origine dal programmatore. Nell ambito della code injection, la SQL injection è l attacco che riveste una maggiore importanza e che spesso presenta gli effetti più devastanti. La principale causa è legata al fatto che le istruzioni SQL siano espresse in forma di concatenazione di stringhe, e ciò le rende facilmente modificabili dall esterno. Il Web Application Security Consortium Glossary [9] fornisce una definizione formale del concetto di SQL injection, descrivendola come An attack technique used to exploit web sites by altering backend SQL statements through manipulating application input, ovvero una tecnica di attacco che sfrutta le vulnerabilità dei siti web che si appoggiano a database di tipo SQL, alterando le query mediante la manipolazione delle informazioni fornite in ingresso. Molte pagine web richiedono infatti l inserimento di particolari parametri da parte dell utente, inoltrando in seguito una specifica query al database SQL, memorizzato sul server. Un semplice esempio è quello della registrazione ad un sito web. All utente viene proposto un form per l inserimento dei propri dati personali (dati anagrafici, nome utente, password). Una volta inserite tali informazioni, esse vengono inviate al server sul quale sarà presente un database, contenente i dati relativi agli utenti registrati fino a quel momento. Verrà quindi inoltrata una query al database per l inserimento di una nuova entry nella tabella degli utenti, contenente le informazioni sul nuovo utente registrato. Ciò sarà utile per la successiva autenticazione dell utente stesso. L attacco di SQL injection sfrutta l inadeguatezza dei controlli sui dati ricevuti dall applicazione web in input (in questo caso mediante il form HTML) per 2

11 CAPITOLO 2. SQL INJECTION inserire codice malevolo all interno di una query SQL, con conseguenze imprevedibili al programmatore e, certamente, devastanti. L attaccante può infatti guadagnarsi un accesso privilegiato a dati ed informazioni riservate e sfruttarle a suo piacimento per portare a termine la propria incursione. Le informazioni accedute illegalmente possono essere non solo lette, ma anche modificate o cancellate. In aggiunta a tutto ciò, alcuni server SQL contengono procedure il cui accesso da parte di un attaccante potrebbe compromettere il funzionamento dell intero sistema. Tutto ciò di cui deve disporre un eventuale attaccante per portare a termine un attacco del genere è un semplice web browser, una pagina web vulnerabile ad attacchi di SQL injection ed una conoscenza più o meno approfondita del linguaggio SQL. Tornando all esempio della registrazione di un utente web, al momento del login egli inserirà il proprio nome utente e la propria password ed una query SQL verificherà che le credenziali di accesso fornite siano corrette. Un potenziale attaccante potrebbe sfruttare tale processo per inserire appositi comandi SQL nel form di login, modificando in tal modo la query ed ottenendo, ad esempio, l accesso al sito senza possedere alcune credenziali di autenticazione. Le tecniche della SQL injection si possono definire di tipo cross platform, esse prescindono infatti dai DBMS utilizzati per fornire un supporto alle applicazioni web, quali ad esempio Oracle, MySQL o MS-SQL. Tuttavia, per ciascuna di essi possono esistere variazioni sia a livello sintattico che a livello comportamentale rispetto ad un determinato attacco. 3

12 CAPITOLO 2. SQL INJECTION 2.2 I bersagli della SQL injection Come è possibile identificare in una pagina web un eventuale vulnerabilità ad attacchi di SQL injection? Il primo passo è identificare il potenziale bersaglio, per poi testarne la vera e propria vulnerabilità. Come illustrato nell esempio del login, possono essere facili bersagli quei siti costituiti da pagine HTML che utilizzano form ed inoltrano informazioni a pagine dinamiche, per esempio ASP o PHP. In tal caso, esistono due possibili metodi di inoltro: GET e POST. Il metodo GET fornisce i parametri inseriti all interno del form HTML rendendoli visibili nell URL, nella forma nome = valore. Questo è il caso più semplice, nel quale modificando semplicemente l URL stesso, contenuto nella barra degli indirizzi del browser, è possibile modificare a proprio piacimento il contenuto della query SQL. Nel secondo caso, con il metodo POST, le informazioni non vengono visualizzate all interno dell URL, ma è sufficiente verificare che nel sorgente HTML della pagina web vi sia una parte di codice del tipo: <FORM action=search.asp method=post> <input type=hidden name=a value=c> </FORM> In tal caso, tutto ciò che è contenuto tra i due tag <FORM> e </FORM> contiene parametri che potranno essere sfruttati per la SQL injection. Oltre alle pagine web contenenti form HTML, si possono individuare vulnerabilità anche nelle stesse pagine dinamiche ASP, JSP, CGI o PHP, nelle quali i parametri sono ottenuti tramite l URL, con una sintassi del tipo: 4

13 CAPITOLO 2. SQL INJECTION In tal caso è ancora possibile inserire codice malevolo modificando semplicemente l URL che compare nella barra degli indirizzi. Una volta individuato un potenziale bersaglio, l attaccante ne deve testare l eventuale vulnerabilità ad attacchi di SQL injection. A tale scopo egli può servirsi di particolari costrutti SQL dati in ingresso all applicazione, al fine di testarne il conseguente comportamento. Tali approcci verranno descritti in dettaglio nelle sezioni successive. 2.3 Test di vulnerabilità alla SQL injection Con lo sviluppo della sicurezza nelle applicazioni web, le vulnerabilità alla SQL injection sono diventate più difficili da identificare e quindi sfruttare. Fino a non molto tempo fa, per un attaccante era sufficiente inserire codice (anche un semplice apostrofo poteva essere sufficiente) che generasse una query non valida e quindi un dettagliato messaggio d errore da parte del server. Le informazioni in esso contenute potevano quindi essere sfruttate per portare a termine l attacco con successo. Vediamo un esempio. Si supponga di accedere al portale web di una libreria che offre all utente la possibilità di ricercare i testi in vendita mediante diversi parametri di ricerca. Supponendo che l utente voglia ricercare il proprio libro inserendo il nome dell autore Smith, il sistema interrogherà il database con la seguente query: SELECT titolo, descrizione, prezzo FROM libri WHERE autore = Smith 5

14 CAPITOLO 2. SQL INJECTION Qualora un attaccante voglia testare la vulnerabilità alla SQL injection, potrà semplicemente effettuare la ricerca inserendo come nome dell autore Smith, aggiungendo quindi semplicemente un apostrofo. Il risultato sarà un messaggio di errore del server di questo tipo: Incorrect syntax near Smith. Server: Msg 105, Level 15, State 1, Line 1 Unclosed quotation mark before the character string Quando l applicazione ha un comportamento simile, l attaccante sa che essa è ampiamente vulnerabile alla SQL injection. Il messaggio d errore testimonia infatti che il sistema non filtra in alcun modo i dati inseriti dall utente ed è quindi possibile utilizzare una delle tecniche che verranno esaminate in seguito per modificare la natura della query. Oggi, nella maggior parte dei casi, i messaggi d errore generati dai server vengono appositamente resi generici o vengono del tutto eliminati per fronteggiare tale problema. Tuttavia, all incremento della sicurezza nelle applicazioni web è corrisposto uno sviluppo di tecniche di attacco più evolute atte ad aggirarla. Esistono quindi altri metodi che possono essere impiegati da un attaccante per testare l eventuale vulnerabilità di un sito web alla SQL injection. In tal caso si parla di Blind SQL injection, in cui l attaccante può sfruttare la debolezza dell applicazione andando, per così dire, alla cieca ed interrogando il database con una serie di istruzioni SQL vere o false per carpire informazioni. A tal proposito, si consideri il seguente esempio. Si supponga di accedere al 6

15 CAPITOLO 2. SQL INJECTION sito di una rivista che offre la possibilità di visualizzare e consultare online le edizioni pubblicate, le cui relative informazioni (data di pubblicazione, descrizione, etc.) sono memorizzate su un apposito database. All utente verrà quindi offerta la scelta dell edizione alla quale vuole accedere ed il server interrogherà il database individuando, ad esempio, la rivista selezionata mediante un identificativo univoco. Supponendo che l utente abbia scelto l edizione il cui corrispondente identificativo è uguale a 7, l URL della pagina in cui verranno visualizzate le informazioni relative a tale edizione sarà del tipo: La query generata per l interrogazione del database sarà quindi la seguente: SELECT * FROM edizioni WHERE id = 7 In tal caso, il server risponderà inviando al client i dati relativi alla settima edizione, che verranno formattati all interno di una pagina HTML e quindi visualizzati dal browser. Per determinare se tale applicazione sia o meno vulnerabile alla SQL injection un attaccante potrà provare ad inserire un ulteriore condizione sempre vera nella clausola WHERE della query, modificando l URL visualizzato nella barra degli indirizzi. Ad esempio, potrà essere richiesto l URL seguente: AND 1=1 7

16 CAPITOLO 2. SQL INJECTION A questo punto, il server potrà assumere due possibili comportamenti. Nel caso migliore, esso sarà stato reso sicuro a sufficienza contro attacchi del genere, mediante una delle tecniche che verranno esaminate più avanti, e quindi rifiuterà l esecuzione della query. Nel caso peggiore, il server eseguirà tranquillamente la query, visualizzerà ancora una volta l edizione richiesta e l utente avrà la certezza di poter passare all attacco, stavolta con esiti sicuramente più disastrosi. 2.4 Tecniche di SQL injection Nell esempio precedente è stata messa in evidenza una delle possibili forme di vulnerabilità alla SQL injection, determinata dall assenza di un controllo sulle informazioni inserite dall utente. Esistono in realtà varie tipologie di vulnerabilità, sfruttando le quali, un attacco di SQL injection, può consentire all attaccante di ottenere risultati differenti. Di seguito verranno analizzate le principali vulnerabilità dalle quali un server SQL può essere affetto ed i relativi attacchi a cui, di conseguenza, esso risulta esposto. Verranno inoltre suggerite alcune contromisure atte a limitare il raggio d azione di tali attacchi Filtraggio inadeguato dei dati in ingresso Tale forma di SQL injection si ha quando le informazioni inserite dall utente non sono opportunamente filtrate e vengono quindi elaborate all interno delle istruzioni SQL senza alcuna verifica preliminare. In tal modo, l utente può manipolare le query di accesso ai database SQL come mostrato nel seguente esempio. Quando un utente registrato ad un sito web vuole effettuare l operazione di login, egli inserisce il proprio nome utente e la propria password mediante un ap- 8

17 CAPITOLO 2. SQL INJECTION posito form HTML di autenticazione. Tali dati vengono inviati al server, il quale li utilizza per interrogare il database degli utenti registrati e verificare la correttezza delle credenziali di accesso fornite. La query SQL impiegata sarà quindi simile alla seguente: SELECT * FROM utenti WHERE nome = + username + AND password = + psw + ; Tale query consente semplicemente di selezionare dalla tabella utenti la riga in cui nome e password corrispondono a quelli forniti per l autenticazione. Un eventuale attaccante può dunque modificare il valore di una delle due variabili per ottenere dalla query un effetto diverso. Ad esempio, inserendo nei campi nome utente e password del form HTML la stringa a OR b = b, egli otterrà la query seguente: SELECT * FROM utenti WHERE nome = a OR b = b AND password = a OR b = b ; Il risultato, in questo caso, sarà l autenticazione dell attaccante, essendo egli riuscito a forzare l accettazione di un nome utente ed una password fittizi, mediante la condizione b = b, che risulta sempre vera. Il linguaggio SQL offre la possibilità di concatenare due query, semplicemente separandole mediante l operatore ;. L interprete identificherà, grazie a tale operatore, le due query distinte e le eseguirà in sequenza. Nel caso dell esempio, inserendo nel campo nome utente del form HTML la stringa a ; DROP TABLE 9

18 CAPITOLO 2. SQL INJECTION utenti; - -, ciò produrrà la seguente query: SELECT * FROM utenti WHERE nome = a ; DROP TABLE utenti ; L operatore - - (così come il carattere di commento # ) serve infatti ad ignorare tutto ciò che lo segue, per cui il risultato sarà l esecuzione delle due query e la conseguente cancellazione dell intera tabella degli utenti. Se i dati inseriti nel form di login fossero stati filtrati e fossero stati eliminati gli apici, l attacco non sarebbe potuto andare a buon fine, poichè l intera espressione sarebbe stata considerata dall interprete come una stringa e si sarebbe semplicemente ottenuto un messaggio di errore indicante l esito negativo del login. Tuttavia, questo è solo un esempio di come questa vulnerabilità possa essere sfruttata da un eventuale attaccante; iniettando infatti alcuni comandi appositi è possibile estendere il raggio d azione dell utente, fino ad assumere il controllo dell intero server SQL. Vediamo alcuni esempi. Accesso alla struttura di un database In alcuni degli esempi fino ad ora illustrati si supponeva che l attaccante avesse una minima conoscenza della struttura interna del database su cui focalizzare il proprio attacco. La concatenazione della query DROP TABLE utenti presupponeva infatti che l utente conoscesse il nome della tabella, contenente i dati degli utenti registrati al sito. In generale, un potenziale attaccante non possiede tali informazioni. Ma è possibile che un utente riesca a scoprire la struttura di un database SQL, le tabelle che lo compongono ed i loro nomi? La risposta purtroppo è si. Vediamo come. Sfruttando ancora l assenza di un filtraggio dei dati in ingresso, un utente ha 10

19 CAPITOLO 2. SQL INJECTION la possibilità di sfruttare degli appositi comandi SQL che consentono di conoscere l elenco delle tabelle facenti parte di un database e la relativa struttura. Nell esempio della consultazione della rivista online, si supponga che l attaccante voglia ottenere un elenco degli utenti registrati al sito, ma non conosca il nome della tabella che ne contiene le informazioni. Il primo passo sarà quindi iniettare nella pagina di ricerca di una specifica edizione, con modalità analoghe a quelle illustrate in precedenza, il codice: 7; SELECT * FROM sys.tables; - -. La query risultante sarà la seguente: SELECT * FROM edizioni WHERE id = 7; SELECT * FROM sys.tables; Il valore numerico 7 viene, ancora una volta, inserito per fornire alla prima query di selezione un parametro valido, successivamente viene ad essa accodata una seconda query che non fa altro che fornire un elenco delle tabelle presenti nel database, il resto viene ignorato con l operatore - -. Una volta noti i nomi delle tabelle presenti nel database, l attaccante potrà tranquillamente visualizzare le informazioni a cui è interessato accodando, in tal caso, una query di selezione sulla tabella degli utenti. Ma le sue opportunità di danneggiare il sistema non sono ancora terminate. Il linguaggio SQL offre infatti la possibilità di modificare le tabelle, sia a livello di struttura che di contenuto. Anche in questo caso l attaccante può sfruttare questa opportunità per mezzo della SQL injection. Con sys.columns egli potrà infatti visualizzare i vari campi di cui è composta una tabella e, una volta noti i loro nomi, potrà modificarli in maniera del tutto arbitraria. Un utente avrebbe dunque la possibilità di guadagnare l accesso privilegiato al database, semplice- 11

20 CAPITOLO 2. SQL INJECTION mente modificando la password di amministratore, attraverso una query di update sulla tabella degli utenti. Ciò dimostra i notevoli rischi a cui è esposta un applicazione web che non prenda le dovute precauzioni per fronteggiare attacchi di SQL injection. Gli strumenti per l accesso alle tabelle di sistema sono forniti da tutti i DBMS, l unica differenza sta nella loro denominazione. Le tabelle sys.tables e sys.columns sono caratteristiche di MS-SQL, ma anche MySQL offre, ad esempio, un sistema analogo detto information schema, così come gli altri DBMS. Si noti comunque che, al fine di determinare la struttura di un database, tale approccio non è sempre adottabile. Nell esempio la SQL injection era effettuata nella pagina di consultazione della rivista, progettata affinchè i risultati della query di ricerca di una specifica edizione venissero in essa visualizzati. Questa rappresenta la condizione ideale per un attaccante: egli può infatti visualizzare sullo schermo qualsiasi informazione venga fuori da una query SQL. Tuttavia, spesso ciò non è possibile. Ne è un esempio il form di login di un utente, che ne consente l autenticazione ma non permette la visualizzazione di alcun risultato di un eventuale query di selezione. È per tale ragione che si parla di Blind SQL injection: l utente deve spesso procedere per tentativi se vuole scoprire il nome di una tabella o la struttura dei suoi campi. Un metodo per rendere un pò più complicata la vita di un attaccante è quindi quello di utilizzare nomi e password che non siano di utilizzo comune o facilmente individuabili dopo pochi tentativi. Oltre all operatore ;, per la concatenazione di più query è possibile sfruttare un altro potente comando SQL: il comando UNION. Esso permette infatti di combinare in un unico insieme di risultati il prodotto di due query effettuate su tabelle differenti, a patto che vengano selezionati un numero ed un tipo di 12

21 CAPITOLO 2. SQL INJECTION campi uguali in entrambe. Nell esempio della libreria online, volendo ricercare tutti i testi appartenenti ad un determinato autore indicato dall utente, si aveva la query seguente: SELECT titolo, descrizione FROM libri WHERE autore = Smith Nell ipotesi in cui un attaccante conosca il nome e la struttura della tabella contenente gli utenti registrati al sito, egli potrebbe utilizzare il comando UNION nel modo seguente: SELECT titolo, descrizione FROM libri WHERE autore = Smith UNION SE- LECT username, psw FROM utenti Ottenendo, in tal modo, l elenco di nome utente e password degli iscritti. Utilizzo di una Stored Procedure Una stored procedure è un programma scritto in linguaggio SQL o in altri linguaggi memorizzato all interno dello stesso database. Generalmente le stored procedures consentono all utente di eseguire query complesse, fornendo una sorta di librerie di sistema precompilate, con un notevole risparmio di tempo e prestazioni, specie durante una comunicazione client-server. L utilizzo delle stored procedures può essere, di per sé, utile ai fini di prevenire eventuali attacchi di SQL injection. Lo sviluppatore può scrivere delle stored procedures ad-hoc che gestiscano i vari tipi di accesso al database e ne definiscano le regole, eliminando del tutto l utilizzo dei comandi SQL, e quindi il problema dell injection. È anche possibile che una stored procedure costruisca essa stessa una query dinamicamente, tuttavia, in tal 13

22 CAPITOLO 2. SQL INJECTION caso, non si ha alcuna protezione dalla SQL injection e sono comunque necessarie particolari contromisure. Il problema delle stored procedure sta nella possibilità del loro utilizzo da parte di eventuali attaccanti. In particolare, in MS-SQL la procedura xp cmdshell può consentire all utente di portare a termine attacchi con effetti molto dannosi sul sistema. Essa consente l esecuzione di un arbitrario comando sul server in maniera analoga a quanto si potrebbe fare con l accesso ad esso mediante il prompt dei comandi. Qualora si abbiano i permessi per effettuare una query di questo tipo, il sistema ne risulterebbe totalmente compromesso. Un altra stored procedure che può rivelarsi potenzialmente dannosa per il sistema è la xp regread, che consente all attaccante la lettura dei registri del sistema operativo. Per fare un esempio, iniettando in una query il seguente codice: ; exec master..xp cmdshell notepad.exe - - è possibile mandare in esecuzione sul server l applicazione notepad. Chiaramente, questo attacco è fondamentalmente innocuo ma si pensi a quali danni potrebbe causare un attaccante eseguendo più volte tale procedura per inviare, ad esempio, al server delle utility che ne consentano il controllo remoto via socket, il furto dei dati, lo sniffing dell eventuale rete interna o altro ancora. Proprio a causa della potenzialità di tale procedura e del rischio ad essa connesso, MS-SQL 2005 ha disabilitato per default tale funzionalità. È chiaro che, per poter eseguire determinate operazioni, è comunque necessario accedere al sistema con privilegi di amministratore, tuttavia spesso la scelta delle credenziali 14

23 CAPITOLO 2. SQL INJECTION di accesso per ottenere questo tipo di autenticazione è particolarmente banale e consente all attaccante di guadagnare tali privilegi con pochi semplici tentativi. È dunque necessario che l applicazione web acceda al database con privilegi limitati al minimo indispensabile: l interrogazione del database con query di selezione e l accesso limitato solo alle tabelle strettamente necessarie. Tuttavia, esistono casi in cui la sola query di selezione non è sufficiente: un utente potrebbe voler modificare i propri dati anagrafici e quindi avere l esigenza di effettuare una query di UPDATE. Una maggiore sicurezza potrebbe essere ottenuta anche configurando il DBMS al momento dell installazione in maniera tale da farlo girare sotto credenziali di accesso che non siano quelle dell amministratore, in tal modo comandi come l xp cmdshell avrebbero un raggio d azione ridotto Assenza di un controllo dei tipi Tale vulnerabilità si ha quando non viene effettuato alcun controllo sui tipi di dato forniti dall utente. Tornando all esempio della consultazione di una rivista online, ciò che il sistema richiedeva per la visualizzazione dell edizione corretta era semplicemente un identificativo numerico. Tuttavia, non veniva effettuato alcun controllo sul tipo di dato ottenuto in ingresso dall utente, al fine di verificare che si trattasse effettivamente di un valore numerico. L attaccante potrebbe infatti rapidamente modificare il parametro fornito al sistema nel modo seguente: TABLE edizioni 15

24 CAPITOLO 2. SQL INJECTION con il risultato della cancellazione delle informazioni relative alle riviste, rendendo quindi inaccessibile la consultazione ad eventuali altri utenti. Inserendo un banale controllo sul tipo di parametro inviato dall utente, si potrebbe impedire tale tipologia di attacco: la query non verrebbe infatti effettuata per un incompatibilità tra i tipi di dato Messaggi di errore ODBC In questa sezione verranno analizzate le tecniche mediante le quali un attaccante può trarre beneficio da un messaggio di errore visualizzato dal server, per portare a termine il proprio attacco con successo. In particolare verranno esaminati i messaggi d errore ODBC. Si prenda in considerazione l esempio dell autenticazione di un utente mediante un form di login, in cui sono previsti i campi nome utente e password. La query generata sarà la seguente: SELECT * FROM utenti WHERE nome = + username + AND password = + psw + ; Si è già visto come un eventuale attaccante possa aggirare tale sistema di login ed autenticarsi in maniera non autorizzata. Tuttavia, per sfruttare tale vulnerabilità al fine di visualizzare, modificare o cancellare le informazioni contenute nel database, l utente necessita di sapere i nomi e la struttura delle tabelle che lo compongono. I messaggi d errore ODBC, se abilitati, forniscono proprio questo genere di informazioni. Si supponga che la tabella contenente le informazioni degli utenti sia stata 16

25 CAPITOLO 2. SQL INJECTION creata con un comando SQL del genere: CREATE TABLE utenti( ID int, username varchar(255), password varchar(255)) Il primo passo per un attaccante è quello di inserire in uno dei campi del form la stringa having 1= In tal modo apparirà il seguente messaggio d errore: Microsoft OLE DB Provider for ODBC Drivers error 80040e14 [Microsoft][ODBC SQL Server Driver] [SQL Server]Column utenti.id is invalid in the select list because it is not contained in an aggregate function and there is no GROUP BY clause. Tale messaggio contiene sia il nome della tabella utenti che il nome del primo campo ID. Il secondo passo dell attaccante sarà quindi sfruttare tali informazioni iniettando il seguente codice: group by utenti.id having 1= Ciò provocherà la visualizzazione di un nuovo messaggio d errore: Microsoft OLE DB Provider for ODBC Drivers error 80040e14 [Microsoft][ODBC SQL Server Driver][SQL Server]Column utenti.username is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause. In tal modo è stato rivelato il nome del secondo campo della tabella utenti: username. Continuando con questa tecnica fin quando non appare più alcun messaggio d errore, un attaccante può riuscire a scoprire la struttura dell intera 17

26 CAPITOLO 2. SQL INJECTION tabella e quindi proseguire con l iniezione di query di modifica o di cancellazione. Sfruttando una tecnica analoga egli può altresì conoscere il tipo di dati contenuti in ciascun campo della tabella. Risulta quindi importante la disabilitazione di tale tipo di messaggi, in modo tale che il server non sia in grado di offrire un così prezioso aiuto ad eventuali intrusi Vulnerabilità dei server SQL Alcuni server SQL sono soggetti a vulnerabilità strettamente legate allo stesso software con i quali sono stati progettati: è un esempio il server MySQL, con la sua funzione mysql real escape string(), che verrà descritta in dettaglio nella prossima sezione. Tale funzione è utilizzata per generare un comando SQL valido a partire da una stringa, quale può essere quella inserita da un utente per l interrogazione di un database. Solo recentemente è stata rilevata una vulnerabilità che si verifica quando si ha a che fare con parametri numerici, che vengono utilizzati in assenza di apici all interno delle query SQL. Dal momento che la funzione mysql real - escape string() riesce a neutralizzare gli attacchi di SQL injection agendo proprio su caratteri speciali come gli apici, in tal caso l attacco riesce a passare inosservato (almeno fin quando non ne saranno visibili le conseguenze!). Questo è solo un esempio di vulnerabilità di un server SQL, le cui debolezze possono essere insite nella stessa implementazione del DBMS adottato. Volendo ad esempio prendere in esame il server MS-SQL, nel 2002 è stata rilevata una grave vulnerabilità che consentiva all utente di autenticarsi con privilegi di amministratore mediante un account di default con nome utente sa e privo di password. Naturalmente potrebbero essere fatti svariati altri esempi di vulnerabilità, ma quanto detto è sufficiente per trarre tre importanti conclusioni. La prima è mai 18

27 CAPITOLO 2. SQL INJECTION fidarsi ciecamente di un DBMS: anche se mette a disposizione strumenti atti a proteggersi da attacchi di SQL injection, l esempio di MySQL dimostra che non è assolutamente certo che tali strumenti siano sicuri a sufficienza. È quindi di notevole importanza adottare alcune contromisure, che verranno descritte di seguito, a prescindere dalla sicurezza offerta dal DBMS in uso. La seconda conclusione è mai utilizzare un DBMS senza averlo configurato opportunamente al momento della sua installazione. I famosi parametri di default spesso costituiscono falle nella sicurezza, in particolare è necessario impostare delle password adeguate. La terza ma non meno importante conclusione è: quando si tratta di sicurezza essere paranoici è fondamentale; il livello di paranoia dev essere direttamente proporzionale all importanza di ciò che vogliamo tutelare! 2.5 Tecniche di protezione da attacchi di SQL injection In questo paragrafo verranno riassunte le varie tecniche utili a proteggersi in maniera efficace da un attacco di SQL injection. Si parlerà, in particolare, dell utilizzo di alcuni accorgimenti nel dare in pasto ad una query le informazioni fornite da un utente e della configurazione adeguata del DBMS. Nella prossima sezione verranno invece analizzati alcuni tool, utili ad individuare e combattere la SQL injection. Si è visto che, nella maggior parte delle applicazioni web, le query al database SQL vengono create in maniera dinamica, dalla fusione tra i comandi inseriti in principio dallo sviluppatore della stessa applicazione ed i parametri forniti dall utente. Grazie agli esempi è stato possibile sottolinerare l importanza di un 19

28 CAPITOLO 2. SQL INJECTION opportuno filtraggio e di un controllo adeguato delle informazioni ottenute in ingresso. L insieme delle operazioni, atte a rendere l input dell utente utilizzabile in maniera sicura per l interrogazione di un database SQL, prende il nome di input sanitizing e si può riassumere nei seguenti passi: Escaping dei caratteri potenzialmente dannosi; Filtraggio dei dati mediante regular expressions; Controllo del tipo di dato ricevuto ed eventuale casting. Un primo passo consiste quindi nell utilizzare la funzione mysql real escape string() (disponibile in MySQL, ma con analoghe funzioni per gli altri DBMS) che consente di filtrare opportunamente caratteri come \ n, \ r, \, gli apici singoli e doppi e così via, facendoli precedere da un backslash. In tal modo è possibile annullare gran parte del codice malevolo iniettato durante un attacco. Tuttavia, tale approccio non è sufficiente. Come già visto nel paragrafo precedente, infatti, esso ha effetto qualora i parametri vengano utilizzati in presenza di apici, come nel caso delle stringhe. È quindi buona norma introdurre gli apici anche in presenza di valori numerici, in modo da rendere comunque efficace l operazione di escaping. Molti linguaggi di scripting, come ad esempio il PHP, che consentono di interfacciarsi con i comandi SQL e di eseguire le relative query, presentano inoltre svariati strumenti per il filtraggio delle informazioni provenienti dall utente, secondo particolari regole appositamente predisposte. Si parla quindi di regular expressions, ovvero di controlli che consentono di stabilire se i dati in input presentano 20

29 CAPITOLO 2. SQL INJECTION un set di caratteri predefinito e nella forma corretta. Nel linguaggio PHP, ad esempio, la funzione ereg consente di verificare che una stringa accettata in ingresso contenga esclusivamente caratteri alfanumerici o rispetti altre regole definite dal programmatore. Di importanza fondamentale è anche il controllo dei tipi, i vari linguaggi offrono operazioni di casting con le quali è possibile neutralizzare alcuni tipi di attacchi. In ogni caso, è opportuno rifiutare un input dell utente che non rispecchi quanto richiesto. Esistono svariate funzioni che consentono di ottenere il medesimo obiettivo, ciò che è importante è verificare sempre la natura dei dati forniti dall utente. L approccio migliore è spesso controllare che l input rispecchi ciò che si richiede, piuttosto che tentare di respingere tutto ciò che è reputato dannoso. L altro aspetto fondamentale per la protezione da attacchi di SQL injection è la corretta configurazione del server SQL. L utilizzo delle stored procedures può essere, come già detto, utile al fine di limitare l accesso dell utente al codice SQL, tuttavia è necessario eliminare o disabilitare tutte quelle procedure potenzialmente dannose o inutilizzate, come ad esempio l xp cmdshell. È altresì importante non connettersi mai al database con privilegi di root: è necessario utilizzare utenti creati appositamente, con diritti molto limitati sul database. Allo stesso modo, non bisogna far girare il DBMS su un sistema con privilegi di amministratore, per limitare il raggio d azione di eventuali attaccanti. Ciò comporta anche la rimozione di tutti gli account inutilizzati ed il potenziamento della sicurezza delle password per quelli in uso. Seppure potrebbe sembrare banale, è fondamentale non diffondere alcuna informazione sulla struttura interna del database: gli esempi hanno evidenziato cosa 21

30 CAPITOLO 2. SQL INJECTION può fare un attaccante che è in possesso di tali informazioni. Un altra tecnica per proteggersi dalla SQL injection consiste nell opportuna configurazione dei messaggi di errore forniti dal server all utente. Si è visto che le informazioni in essi contenute possono essere di grande aiuto all attaccante per perseguire i propri obiettivi. È oltretutto importante considerare che strumenti come i firewall o gli IDS (Intrution Detection Systems) forniscono una protezione inadeguata nei confronti di attacchi web su larga scala, come la SQL injection. Proprio perchè l applicazione web dev essere pubblica ed accessibile dagli utenti esterni, tali sistemi consentiranno qualsiasi traffico (attraverso la porta 80) per la comunicazione con il database mediante l applicazione web. La configurazione di tali strumenti ed il loro aggiornamento è quindi certamente fondamentale ma non sufficiente per proteggersi da attacchi di SQL injection. Infine, può essere di valido aiuto l utilizzo di appositi tool per l analisi delle possibili vulnerabilità cui è esposto un server. Nella prossima sezione ne verranno analizzati alcuni tra i più diffusi. 2.6 Alcuni strumenti utili Quanto detto finora sui possibili attacchi di SQL injection porta alla necessità di una verifica delle proprie applicazioni web, allo scopo di identificare e correggere eventuali vulnerabilità. Vista la molteplicità degli attacchi possibili, è chiaro che testare in maniera esaustiva un applicazione web per portare alla luce tutte le possibili falle nella sicurezza, dette security holes, può rivelarsi difficile (se non impossibile), a meno che non vengano impiegati dei tool specifici che effettuano in maniera automatizzata tali controlli. 22

31 CAPITOLO 2. SQL INJECTION Gli strumenti per l identificazione delle generiche vulnerabilità delle applicazioni web sono oggi molto diffusi e ne sono disponibili svariati in rete. In particolare, per quanto riguarda gli attacchi di SQL injection vi sono numerosi strumenti, detti SQL injection Scanners, che hanno come obiettivo proprio l analisi dettagliata di un applicazione web alla ricerca di eventuali security holes. Tra gli strumenti gratuiti più diffusi citiamo i seguenti: SQLier [5]: presenta un interfaccia a linea di comando, consente di analizzare un dato URL per ricercare ed eventualmente sfruttare vulnerabilità alla SQL injection; SQLibf - SQL Injection Brute Forcer [4]: consente di determinare il livello vulnerabilità alla SQL injection (visibile e blind) di un applicazione web; Absinthe [1]: tool ad interfaccia grafica che consente il reperimento di struttura e contenuti di un database vulnerabile alla blind SQL injection; Sqlmap [6]: tool ad interfaccia testuale sviluppato in Phyton che permette di reperire numerose informazioni relative ai database memorizzati su un server, alla loro struttura, al contenuto delle tabelle ed altro ancora; SQL Power Injector [3]: strumento che consente di testare vulnerabilità, automatizzando svariate tecniche di blind SQL injection. Paros Proxy [2]: proxy server HTTP/HTTPS con funzionalità di pen testing (penetration testing) per svariati tipi di vulnerabilità, tra cui SQL injection e cross-site scripting. 23

32 CAPITOLO 2. SQL INJECTION Nel capitolo 4 verrà trattato in dettaglio il funzionamento dell ultimo strumento citato, Paros, un tool molto potente per testare la sicurezza delle applicazioni web. 24

33 Capitolo 3 Cross Site Scripting 3.1 Introduzione Sebbene il Cross-Site Scripting (XSS) costituisca una piccola fetta nel panorama della sicurezza delle applicazioni web, esso rappresenta una delle minacce più grandi e devastanti. Molta gente non comprende l effettivo pericolo che possono rappresentare le vulnerabilità ad attacchi di XSS e come esse possano essere usate regolarmente a discapito di vittime ignare, quali i comuni utenti di internet. Il cross-site scripting è un attacco che consente di accedere ad informazioni sensibili, rubare dati di sessione degli utenti, compromettere i browser web che essi utilizzano o, ancor peggio, l integrità del sistema su cui tali browser stanno eseguendo. Le vulnerabilità all XSS esistono fin dagli albori della storia del World Wide Web, ma oggi rappresentano un imponenente minaccia, specialmente per l industria sempre in crescita dell e-commerce. Il cross-site scripting si può considerare come una forma di code injection, in cui l attaccante inietta specifici tag HTML o codice JavaScript malevolo (malware), dal quale non è possibile proteggersi mediante i classici sistemi antivirus. I worm XSS, infatti, riescono a diffondersi sfruttando le vulnerabilità delle applicazioni web al cross-site scripting e, qualora siano presenti eventuali bug nei browser in 25

34 CAPITOLO 3. CROSS SITE SCRIPTING uso, possono compromettere il sistema stesso che li esegue. A differenza dagli attacchi web di SQL injection, esaminati nel capitolo precedente, gli attacchi di cross-site scripting riguardano contenuti dinamici e non. Nel caso di pagine web statiche è infatti possibile effettuare la cosiddetta HTML injection, ovvero l inserimento di tag HTML che verranno di conseguenza processati dal browser in uso. Un altra differenza sostanziale tra SQL injection ed XSS sta nel fatto che, mentre la prima è caratterizzata da attacchi lato server, finalizzati alla cattura delle informazioni memorizzate o al controllo del server stesso, il cross-site scripting è un attacco che agisce prettamente lato client, mediante l esecuzione, da parte del browser, del codice malevolo inettato. Gli obiettivi sono fondamentalmente analoghi nei due casi: cattura di informazioni riservate, danni al sistema, controllo dell eventuale rete interna, e così via. Come per la SQL injection, qualora lato server non vi sia alcun filtraggio delle informazioni inserite dagli utenti, tutti i browser con JavaScript abilitato saranno potenzialmente vulnerabili. 3.2 Tipologie di Cross-Site Scripting Il cross-site scripting è una tecnica d attacco che riesce a forzare il browser web all esecuzione e visualizzazione di codice malevolo, contenuto nell applicazione o nella pagina web cui l utente accede. Generalmente scritto nei linguaggi HTML o JavaScript, il malware XSS non esegue sul server che lo ospita, bensì lato client. L attaccante sceglie quindi un applicazione web vulnerabile al cross-site scripting, inietta il proprio codice malevolo al suo interno ed attende che un ignaro utente si colleghi al sito in questione. Quando il client visualizza la pagina web contenente il worm XSS, ne effettua l esecuzione mediante il browser e, a quel 26

35 CAPITOLO 3. CROSS SITE SCRIPTING punto, l attaccante può ottenere pieno potere sulla vittima: il furto delle informazioni sensibili, l hacking dell eventuale intranet, l accesso alla cronologia sono solo alcuni degli aspetti di questo tipo di attacco. Come già accennato, il primo passo di un attaccante sta nell upload del proprio malware nel sito web designato ad ospitarlo. Esistono diversi metodi attraverso i quali tale operazione può essere effettuata: 1. Il proprietario del sito web è proprio l attaccante, quindi ha inserito deliberatamente il malware; 2. Sfruttando una vulnerabilità del sistema operativo o di livello Network, l attaccante è riuscito ad inviare al server il malware creato; 3. L attaccante ha inserito il proprio codice XSS attraverso una zona del sito vulnerabile; 4. L attaccante crea e diffonde un link apposito che collega ad una pagina web, la cui visualizzazione provoca l esecuzione del malware. Un semplice esempio di cross-site scripting con i metodi 1 e 2 è l iniezione all interno di una pagina HTML del seguente codice: <script src = /> Utilizzando semplicemente il tag HTML script, in tal modo, è possibile richiamare il malware XSS, memorizzato all URL specificato. Per i metodi 3 e 4, è prima di tutto necessaria l identificazione di un applicazione web vulnerabile ad attacchi XSS. In tal caso, l utente vittima dell attacco 27