Aggiornato al : mag 7, 2008
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:
http://www.sitoweb.it/index.asp?id=10
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.
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’
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 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:
http://www.la-mia-rivista.com/edizione.php?id=7
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:
http://www.la-mia-rivista.com/edizione.php?id=7 AND 1=1
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.
Articolo Precedente -> Introduzione all’SQL injection
Articolo Successivo -> Tecniche di Sql Injection
http://www.intilinux.com/sicurezza/685/tecniche-di-sql-injection-filtraggio-inadeguato-dei-dati-in-ingresso-accesso-alla-struttura-di-un-database-utilizzo-di-una-stored-procedure/
Autore : Simon. U
marzo 24th, 2009 at 01:03
alert(‘XSS’)
Rispondi
giugno 11th, 2009 at 19:53
dsfsdfs67877 test test
Rispondi