Wikipedia scrive che "La SQL injection è una tecnica dell'hacking mirata a colpire le applicazioni web che si appoggiano su un database di tipo SQL", ossia qualsiasi sito web dinamico (quindi appoggiato ad un database) è potenzialmente in pericolo. Questo metodo d'attacco mira a conoscere le caratteristiche dell'archivio quali nome tabelle, nome campi, contenuti dei campi e quindi se va a buon fine può accedere in scrittura sul database con conseguenze gravi sulla funzionalità, sulla sicurezza, sulla privacy e sull'attendibilità dell'applicazione WEB.
Come viene generata una pagina dinamica? Quali strumenti l'hacker utilizza nell'SQL injection? Come è possibile che questo accada?
Quando un utente si trova su un sito dinamico interagisce con esso "passando dei parametri": per esempio se clicca su un link per vedere tutti i prodotti della categoria "CALCIO" invia al server un parametro del tipo categoria='calcio' mentre nel link dei prodotti che riguardano il TENNIS il parametro sarà categoria="tennis". A questo punto il server interroga l'archivio in base alla richiesta e genera al volo la pagina html che viene poi visualizzata sul browser. Nel caso il sistema utilizzi il metodo del GET questi parametri vengono visualizzati sulla barra degli indirizzi del browser in aggiunta all'indirizzo della pagina web, mentre se l'applicazione utilizza un form basato su POST i parametri sembrano nascosti ma sono sempre visibili visualizzando il codice HTML della pagina. Quindi in tutti i casi sono in chiaro e chiunque può accedere a queste informazioni. Bisogna sottolineare che questi dati non contengono i nomi delle tabelle e dei campi del database ma solo eventualmente i dati contenuti necessari al sistema (nel nostro esempio pallone modello mondiale, pallina bianca, pallina gialla professionale).
L'hacker, utilizzando un normalissimo browser, invia dei parametri con dei caratteri particolari che mandano in errore il server il quale in genere oltre a segnalare il codice del problema si lascia sfuggire anche preziose informazioni. L'SQL injection fa scoprire prima di tutto i nomi delle tabelle del database, poi i nomi dei campi e il tipo (campi numerici, alfanumerici, indici); a questo punto si potrebbe tranquillamente cancellare, modificare o peggio aggiungere dei dati. Aggiungere un record nella tabella degli utenti potrebbe far accedere all'applicazione web e alla console di amministrazione della stessa. Inviando dei parametri più complessi ma comunque alla portata di chiunque l'hacker è in grado addirittura di scoprire i contenuti dei campi andando a compromettere la privacy e la sicurezza del sistema. Invece quello più giocherellone, sempre passando dei parametri, potrebbe cancellare intere tabelle.
Ogni applicazione WEB è quindi potenzialmente in pericolo se non si adottano delle semplici regole che andremo a analizzare.
La cosa più importante da fare per proteggere un sito dinamico da attacchi di tipo SQL Injection è il controllo e la validazione dei parametri passati al sistema siano essi di tipo GET che POST, in pratica quella che in inglese viene definita "Input Validation".
Si potrebbe quindi pensare di utilizzare uno di questi tre metodi:
- controllare e modificare l'INPUT in modo da renderlo valido;
- rifiutare l'INPUT che si conosce come dannoso al sistema;
- accettare solamente l'INPUT che si conosce come inoffensivo.
Utilizzare solamente una di queste tecniche non è ottimale in quanto tutte hanno dei limiti: per esempio se si utilizza il metodo del rifiuto o la modifica dell'INPUT si presuppone di conoscere tutte le combinazioni di parametri pericolosi mentre questo è impossibile perché ogni giorno l'hacker scopre nuove strade.
La via più sicura è quella di utilizzarle tutte anche se potrebbe sembrare una duplicazione dei controlli. Di seguito degli esempi concreti per ciascun metodo.
CONTROLLO E MODIFICA DELL'INPUT
Per prima cosa consiglio di controllare ed eventualmente tagliare il parametro quando troppo lungo di quanto dovrebbe: se per esempio il form fa scegliere la provincia il parametro deve essere di due caratteri, se è superiore qualcuno fa il furbetto e allora noi lo tagliamo prendendo solamento i primi due caratteri della stringa. In pratica ogni parametro passato non deve essere più lungo del campo del database a cui si riferisce. Poi è buona regola eliminare alcuni caratteri potenzialmente pericolosi come la virgoletta singola (') o il meno (-) anche se può sembrare una limitazione nel contenuto dei campi.
RIFIUTO DELL'INPUT DANNOSO
A questo punto si controlla ed eventualmente si rifiuta completamente la richiesta dell'utente quando
si riconosce del codice dannoso. Attenzione che il codice dannoso molte volte viene codificato in HTML. Per esempio si deve sempre rifiutare "select", "insert", "update", "delete", "drop", "--", "'".
ACCETTARE L'INPUT VALIDO
In questo caso tornando all'esempio della provincia il sistema dovrà accettare solamente dei caratteri alfabetici maiuscoli, se si trova una lettera minuscola, un numero o un qualsiasi altro carattere non alfabetico maiuscolo l'INPUT non verrà accettato.
Proviamo a vedere cosa succede nell'utilizzo congiunto delle tre tecniche di protezione sopra descritte quando il parametro riguarda il CAP (codice avviamento postale italiano).
L'hacker passa come parametro la stringa CAP=--'12345. Il primo controllo la taglierą prendendo i prime cinque caratteri (CAP=--'12) ed eliminerà dei caratteri (CAP=12). Per il secondo controllo e il terzo tutto ok.
L'hacker passa come parametro la stringa CAP=1drop2345. Il primo controllo la taglierà prendendo i prime cinque caratteri (CAP=1drop), il secondo controllo troverà la stringa "drop" e rifiuterà l'INPUT.
L'hacker passa come parametro la stringa CAP=12345delete. Il primo controllo la taglierà prendendo i prime cinque caratteri (CAP=12345). Per il secondo controllo e il terzo tutto ok.
Tutto ciò può sembrare un eccesso di controllo ma visto l'intelligenza e l'astuzia di chi fa gli attacchi SQL injection, solamente l'utilizzo delle tre tecniche porta ad un adeguato livello di sicurezza.