Cos'e' SQL.
SQL e' un linguaggio di programmazione molto usato, soprattutto in ambito web, per accedere a dati contenuti in database. Esistono varie implementazioni di SQL, per esempio: MySQL (sia per Windows che per Unix), MS SQL (SQL di casa Microsoft), Oracle, etc.. Ognuna di queste e' generalmente fornita di un server e di un client, dal quale possiamo inviare i comandi che aderiscono, o almeno dovrebbero, allo standard stabilito dall'istituto ANSI.

Come si usa.
L'accesso ai database si ottiene tramite delle query (letteralmente 'richieste') che l'utente invia. Tramite la query si possono fare ricerche nel database, modificare contenuti e ottenere dati importanti.
Una query possibile e' la seguente
CODICE
SELECT * FROM users

Essa "seleziona" e ci fornisce tutti (*) i campi appartenenti alla tabella chiamata utenti. Ecco un altro esempio:
CODICE
SELECT * FROM users WHERE posts > 1000

Oppure questa query potrebbe fornirci tutti gli utenti di un forum che hanno piu' di mille post.

Cos'e' l'SQL Injection.
L'SQL Injection e' l'iniezione, appunto, di codice SQL in una normale query che il programma in esecuzione su un sito usa per accedere ai dati del database.
Essa puo' essere utilizzata quando sui dati inseriti dall'utente non viene effettuato nessun controllo e il codice SQL che lui inserisce viene eseguito sul database. Come immaginate potendo eseguire query arbitrarie si possono fare moltissime cose, come leggere le password degli utenti contenute in un database (o gli hash), modificarle, o anche cancellare tutto il contenuto del database. In alcuni casi, quando si puo' effettuare l'SQL Injection in un pannello di login, essa puo' essere usata per bypassare la protezione e quindi avere accesso non autorizzato a zone limitate di un sito, come per esempio l'intranet che molte aziende mettono a disposizione dei dipendenti per lavorare da casa.
Spesso anche se il contenuto di una form di login viene controllato si puo' effettuare l'SQL Injection in molti altri modi per esempio in una form di ricerca oppure anche nei parametri che vediamo nell'url di un sito: infatti molto spesso ci capita di vedere url in questa maniera:
CODICE
http://www.sito.com/gallery.php?cat=sport&dimension=1024

Probabilmente le variabili come cat e date vengono passate a SQL per filtrare solo i risultati che corrispondono ai criteri, cioe' immagini nella categoria sport e di dimensioni 1024.
L'SQL Injection puo' essere sfruttata, abbiamo detto, quando per un errore di programmazione l'input inserito dall'utente non viene controllato a dovere. Vediamo come viene generata una query SQL in php e come avviene il meccanismo dell'SQL Injection.
CODICE
$sql = "SELECT * FROM posts WHERE title ='" . $title_search "'";

Questa e' una query totalmente inventata, comunque dovrebbe restituire tutti i post di un forum dove il campo titolo corrisponde al titolo cercato dall'utente, contenuto nella variabile $title_search. Quando l'utente inserisce qualcosa tipo "Linux" la query contenuta nella variabile $sql sara' in questa maniera:
CODICE
SELECT * FROM posts WHERE title ='Linux'

E fin qui niente di strano.
Ma vediamo cosa succede se l'utente inserisce un singolo apice e quindi come titolo la stringa "' Linux": la query diventa:
CODICE
SELECT * FROM posts WHERE title ='' Linux'

Come vedete il primo apice della stringa che l'utente ha inserito, e che non viene controllato correttamente, cambia totalmente il significato della query, in questo caso infatti cerchera' i post con titolo vuoto, ma anzi, probabilmente riceveremo un errore di sintassi per quel Linux' che segue (l'apice dopo linux e' quello aggiungo dal codice PHP automaticamente).
Questo puo' essere molto utile solo per verificare se il server e' vulnerabile a questo tipo di attacco, infatti se la pagina che otteniamo e' una pagina che ci segnala l'errore di SQL il sito e' vulnerabile; se invece ci viene fornita una pagina con scritto che, per esempio, la nostra ricerca ha avuto esito negativo, probabilmente il sito ha corretto l'input da noi inserito.
Oltre a questo dobbiamo affinare le nostre skills per riuscire a ottenere qualcosa di piu', oltre a sapere se il server e' vulnerabile.
Per separare due query si usa il punto e virgola, quindi possiamo inserire un punto e virgola dopo il primo apice e inserire una nuova query SQL da eseguire!! Vediamo un esempio che succede inserendo: "'; DROP * FROM users -- " La query diventa:
CODICE
SELECT * FROM posts WHERE title = ''; DROP * FROM users --'

Ecco cosa abbiamo fatto.
Con il punto e virgola abbiamo chiuso la prima query di cui non ci interessa nulla, ne se restituisce qualcosa o meno. Il punto importante e la seconda: il comando DROP serve per rimuovere record dai database e noi abbiamo rimosso tutti i record contenuti nel database utenti. I due trattini indicano l'inizio di un commento e ci servono per fare ignorare al programma il secondo apice che altrimenti avrebbe generato un errore di sintassi.
Come vedete l'SQL Injection e' un attacco che ammette molte possibilita' di utilizzo, da quelle che permettono di leggere dati riservati in un database (per esempio gli hash delle password contenuti nei database dei forum), a quelle che ci permettono di modificare i dati stessi o di distruggerli.
L'errore di programmazione che permette l'SQL Injection e' molto frequente e spesso capita anche nei pannelli di login di siti di aziende o istituzioni (mi e' capitato di vederne smile.gif che permettono l'accesso ai dipendenti da casa. Ecco un esempio preso da un vero sito.
La pagina per accedere all'intranet chiedeva il cognome del dipendente e una password. Provando a inserire un singolo apice nel campo password si riceveva un errore del server nel codice ASP, e questo era molto utile per ricostruire la query SQL che veniva inviata, molto simile a questa:
CODICE
SELECT * FROM database WHERE username = '$username' AND password = '$passwd'

Ovviamente $username e $passwd sono le variabili che contengono quello che l'utente ha inserito nei rispettivi campi delle form.
Questa query cerca nel database un campo in cui sia il nome utente sia la password corrispondano a quelli inseriti dall'utente, quindi se non li trova restituira' un risultato negativo e l'accesso non sara' consentito. Noi dobbiamo fare in modo che il risultato restituito dalla query sia sempre positivo, come fare? E' abbastanza semplice, possiamo inserire una condizione sempre vera (per esempio 1=1, 2=2 etc..) dopo la verifica della password. Nel campo utente inseriamo un utente esistente, non ci vuole molto a procurarsi il cognome di un dipendente; nel campo password inseriamo questo:
CODICE
' OR '1'='1

Ecco come la query diventa:
CODICE
SELECT * FROM database WHERE username = '$username' AND password = '' OR '1'='1'

E adesso la query cerchera' un campo con il nome utente che abbiamo inserito e, o la password vuota (cosa molto improbabile) e 1 = 1 (cosa sempre vera). In questa maniera restituira' un risultato positivo e avremo accesso a rete privata. Forse vi puo' sembrare qualcosa di troppo semplice, ma vi assicuro che ci sono molti siti ancora vulnerabili e anche in alcuni forum molto usati come phpbb, vulnerabilita' di questo genere erano molto frequenti.
Contromisure poco efficaci
Una contromisura adottata spesso in questi casi e' quella di raddoppiare gli apici, cioe' un singolo apice (') viene sostituito da due (''). Ecco come diventa la prima query se si fosse adottata questa protezione e avendo inserito la stringa "Lin'ux".
CODICE
SELECT * FROM posts WHERE title ='Lin''ux'

Cosi' non viene generato nessun errore, ma questa protezione e' molto spesso facilmente superabile, ecco come: molti database permettono, per inserire un singolo apice nella stringa, di farlo precedere dal carattere \ (backslash). Ecco che succede se noi inseriamo come stringa "Lin\'; COMANDO SQL --":
CODICE
SELECT * FROM posts WHERE title ='Lin\''; COMANDO SQL --'

Da notare che la funzionalita' di poter inserire due query SQL in una sola stringa, separate da un punto e virgola non e' supportata da tutti i tipi di database, o in genere e' disabilitata per motivi di sicurezza. In questa maniera l'apice preceduto da \ viene interpretato proprio come un apice all'interno della stringa e non come l'apice di chiusera, mentre il secondo apice, inserito automaticamente dal meccanismo di protezione, chiude la stringa. Con il punto e virgola terminiamo quella query e possiamo inserire un altro comando SQL, sempre ricordandoci che dobbiamo chiudere con un commento per evitare che l'apice finale che avanza generi un errore di sintassi.
In alcuni casi, non sono solo gli apici che possono provocare un inserimento di codice, ecco un altro esempio. Ammettiamo che venga richiesto un codice numerico per loggarsi con una query simile a questa:
CODICE
SELECT * FROM users WHERE code = $code

Come sempre $code e' cio' che inserisce l'utente, quindi se inserisce un numero non c'e' nessun problema. Ma si puo' sempre inserire questa stringa: "0 OR 1=1". La query diventa:
CODICE
SELECT * FROM users WHERE code = 0 OR 1=1

e si ottiene sempre l'accesso.

Come difendersi.
Generalemente bisognerebbe permettere all'utente di inserire solo i dati che sappiamo essere innocui, e non impedire di inserire quelli che sappiamo essere pericolosi. Per esempio in una form dove va inserita una email e' inutile permettere l'utilizzo di caratteri come singoli o doppi apici, parentesi angolari che non possono essere usati in un indirizzo email. Percio' sarebbe opportuno disabilitare l'input di TUTTI i caratteri tranne:
CODICE
abcdefghijklmopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789@-._

che sono gli unici a poter essere usati all'interno dell'email. Se proprio non si puo' evitare di estromettere alcuni caratteri dall'elenco di quelli ammessi, bisogna assicurarsi di controllare sempre quello che l'utente inserisce e di rendere input malintenzionati innocui.
Un'altra misura da adottare al fine rendere piu' difficile l'exploiting di una applicazione e' quella di NON mostrare i messaggi di errore di SQL, poiche' possono essere molto utili per ricostruire la struttura di una query SQL (e di conseguenza dell'intero database) a un attaccante, che invece farebbe molta piu' fatica senza avere a disposizione queste informazioni.