|
|
|
< 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 il Corso T-SQL su Asp 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".
Codice:
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
Codice:
ID=' ' ' AND PASSWORD=' '
Questo ci aiuta a fare ipotesi sul codice sorgente, che potrebbe includere un comando simile a questo
Codice:
Select * from tabella where ID=' username ' AND PASSWORD=' pass '
Questa striga 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.
guida scritta da:
- Chris Anley, "Advanced SQL injection in SQL Server applications", 2
- Marco Bonzanini, Proteggersi dalla SQL Injection
- Mike Schiffman, Scacco agli hacker, Milano, Apogeo 2002
- S. McClure, J.Scambray e G.Kurtz, Hacker! 4.0, Milano, Apogeo 2003
|
|
