Tecniche di SQL injection :Filtraggio inadeguato dei dati in ingresso, Accesso alla struttura di un database, Utilizzo di una Stored Procedure »
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 apposito 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 a
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 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 pre supponeva 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 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, semplicemente 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. E 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
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 SELECT 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 se 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. E anche possibile che una stored procedure costruisca essa stessa una query dinamicamente, tuttavia, in tal 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à. E chiaro che, per poter eseguire determinate operazioni, è comunque necessario accedere al sistema con privilegi di amministratore, tuttavia spesso la scelta delle credenziali di accesso per ottenere questo tipo di autenticazione è particolarmente banale e consente all’attaccante di guadagnare tali privilegi con pochi semplici tentativi.
E’ 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.
Articolo Precedente -> I bersagli della SQL injection : test di vulnerabilità
Autore : Simon. U
Tags:
Sicurezza, SQL Injection
Se sei alle prime armi con Linux fai la tua richiesta alla sezione Help per inesperti su InTiLinuX Forum.
Nessun commento