Nella sicurezza informatica SQL injection è una tecnica di command injection, usata per attaccare applicazioni che gestiscono dati attraverso database relazionali sfruttando il linguaggio SQL. Il mancato controllo dell'input dell'utente permette di inserire artificiosamente delle stringhe di codice SQL che saranno eseguite dall'applicazione server: grazie a questo meccanismo è possibile far eseguire comandi SQL, anche molto complessi, dall'alterazione dei dati (es. creazione di nuovi utenti) al download completo dei contenuti nel database.
Storia Le prime discussioni pubbliche relative all'SQL injection sono apparse attorno al 1998. Per esempio, un articolo del 1998 su Phrack Magazine.
Descrizione Sfrutta le vulnerabilità di sicurezza del codice applicativo che si collega alla fonte dati SQL, ad esempio, sfruttando il mancato filtraggio dell'input dell'utente (es. 'caratteri di escape' nelle stringhe SQL) oppure la mancata tipizzazione forte delle variabili impiegate. È più conosciuto come attacco destinato ad applicazioni web, ma è anche usato per attaccare qualsiasi altro tipo di applicazione che impieghi in modo non sicuro database SQL.
Permette agli attaccanti di effettuare attività di spoof identify, modificare dati esistenti, causare repudiation issues come l'annullamento di transazioni o la modifica dei bilanci, permette di ottenere tutti i dati sul sistema, eliminare o rendere inaccessibile dei dati, e creare o compromettere gli utenti (e.g. amministratore) del database server.
In uno studio del 2012, è stato osservato che in media le applicazioni web ricevono 4 attacchi al mese, ed i rivenditori ricevono il doppio degli attacchi rispetto alle industrie.
Tipi di SQL injection L'SQL injection (SQLI) è considerata da Open Web Application Security Project una delle 10 maggiori vulnerabilità delle applicazioni web nel 2007 e nel 2010. Nel 2013 e nel 2017 SQLI è stato considerato il numero uno degli attacchi sulla OWASP top 10. Ci sono quattro principali sotto classi di SQL injection: Classic SQLI Blind or Inference SQL injection Database management system-specific SQLI Compounded SQLI SQL injection + insufficient authentication SQL injection + DDoS attacks SQL injection + DNS hijacking SQL injection + XSS
Lo Storm Worm è un esempio di utilizzo delle Compounded SQLI.
Questa classificazione dello stato dell'SQLI rappresenta la sua evoluzione fino al 2010.
Implementazioni tecniche Caratteri di escape non filtrati correttamente Questo tipo di SQL injection si verifica quando non viene filtrato l'input dell'utente dai caratteri di escape e quindi vengono passati all'interno di uno statement. Questo può provocare la manipolazione degli statements eseguiti sul database dagli utenti finali dell'applicazione.
La seguente linea di codice illustra questo tipo di vulnerabilità:
statement = "SELECT * FROM users WHERE name = '" + userName + "';"
Questo codice SQL recupera tutti i record che hanno un certo username dalla tabella users. Tuttavia, se un utente malintenzionato scrive la variabile “userName” in un certo modo, lo statement SQL può fare più di quello che era inteso dall'autore del codice. Per esempio, impostando la variabile “userName” come:
' OR '1'='1 Oppure usando dei commenti per non fare eseguire il resto della query (ci sono tre tipi di commenti SQL). Tutte e tre le linee hanno uno spazio alla fine: ' OR '1'='1' -- ' OR '1'='1' ({ ' OR '1'='1' /*
Ecco come appare il rendering dello statement SQL dopo l'inserimento di una delle linee di codice con commento e senza:
SELECT * FROM users WHERE name = '' OR '1'='1'; SELECT * FROM users WHERE name = '' OR '1'='1' -- ';
Se questo codice fosse utilizzato in una procedura di autenticazione, allora questo esempio potrebbe essere usato per forzare la selezione di tutti i campi dati (*) di "tutti" gli utenti piuttosto che di un singolo username come era inteso dal codice, ciò accade perché la valutazione di ‘1'='1' è sempre vera (short-circuit evaluation).
Nell'esempio di sotto il valore di “userName” causerebbe l'eliminazione della tabella “user” e la selezione di tutti i dati nella tabella “userinfo” (in pratica rivelando le informazioni di tutti gli utenti), usando un API che permette statement multipli: a'; DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't
L'inserimento dell'input specificato sopra fa diventare lo statement SQL in questo modo:
SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';
Mentre molte delle implementazioni dei server SQL permettono di eseguire statement multipli con un'unica chiamata, alcune di queste API come nella funzione mysql_query() di PHP non lo permettono per motivi di sicurezza. Questo evita che gli attaccanti iniettino delle query completamente separate all'interno dello statement, ma ciò non li ferma dal modificarle.
Gestione non corretta del tipo Questo tipo di SQL injection si verifica quando un campo fornito dall'utente non è fortemente tipizzato o non vengono controllati i vincoli sul tipo. Questo può accadere, ad esempio, quando viene utilizzato un campo numerico in uno statement SQL, ma il programmatore non fa controlli per verificare che l'input immesso dall'utente sia effettivamente numerico. Per esempio: statement:= "SELECT * FROM userinfo WHERE id = " + a_variable + ";"
Da questo statement è evidente che l'autore voleva che la variabile fosse un numero riferito al campo "id". Tuttavia se essa è di fatto una stringa, allora l'utente finale potrebbe manipolare lo statement a suo piacimento, e quindi aggirare la necessità di caratteri di escape. Per esempio, impostando una variabile a
1;DROP TABLE users
Viene fatto il drop (eliminazione) della tabella "users" dal database, visto che lo statement SQL diventa:
SELECT * FROM userinfo WHERE id=1; DROP TABLE users;
Blind SQL injection
Il Blind SQL Injection è usato quando un'applicazione web è vulnerabile ad SQLI ma i risultati dell'operazione non sono visibili all'attaccante. La pagina con la vulnerabilità potrebbe non essere una che mostra dei dati, ma può essere visualizzata differentemente a seconda del risultato dello statement di tipo logico iniettato dentro lo statement SQL originale, chiamato per quella pagina. Questo tipo di attacco può impiegare un notevole dispendio di tempo perché bisogna creare un nuovo statement per ogni bit recuperato. Ci sono vari strumenti che permettono di automatizzare questi attacchi una volta che sono state individuate le vulnerabilità e qual è l'informazione obiettivo.
Risposte condizionali
Uno dei tipi di blind SQL injection forza il database a valutare uno statement logico su un'ordinaria schermata dell'applicazione. Ad esempio, un sito di recensioni sui libri usa una query string per decidere che recensione su quale libro mostrare. Quindi l'URL http://books.example.com/showReview.php?ID=5 farà eseguire al server la query SELECT * FROM bookreviews WHERE ID = 'Value(ID)'; Con la quale popolerà la pagina con i dati della recensione con ID 5, memorizzati nella tabella bookreviews. La query viene eseguita completamente sul server; quindi l'utente non saprà i nomi del database, della tabella, o dei campi, e nemmeno conoscerà la query string. L'utente vedrà soltanto che l'URL di sopra ritorna la recensione di un libro. Un Hacker può caricare i seguenti URL http://books.example.com/showReview.php?ID=5 OR 1=1 e http://books.example.com/showReview.php?ID=5 AND 1=2, che potrebbero generare rispettivamente l'esecuzione di queste query: SELECT * FROM bookreviews WHERE ID = '5' OR '1'='1'; SELECT * FROM bookreviews WHERE ID = '5' AND '1'='2'; Se utilizzando l'URL con "1=1" viene caricata la recensione originale e con l'URL che ha "1=2" viene caricata una pagina bianca o d'errore, e la pagina ritornata non mostra all'utente che è appena stato inserito un URL non valido, è molto probabile che il sito sia vulnerabile ad attacchi di SQL injection perché vuol dire che entrambe le query potrebbero essere state eseguite correttamente dal database server. L'hacker potrebbe eseguire la seguente query string per venire a conoscenza del numero di versione di MySQL presente sul server: http://books.example.com/showReview.php?ID=5 AND substring(@@version, 1, INSTR(@@version, '.') - 1)=4, una volta eseguita mostrerebbe la recensione del libro se il server utilizza MySQL 4 ed altrimenti una pagina bianca o d'errore. L'hacker può continuare ad usare del codice all'interno delle query string per ottenere sempre più informazioni sul server fino a quando non viene scoperta una nuova via di attacco oppure fino a quando i suoi obiettivi non siano raggiunti.
Second order SQL injection Il Second order SQL injection si verifica quando i valori inviati dall'utente contengono comandi maligni che vengono salvati sul server piuttosto che venire eseguiti immediatamente. In alcuni casi, l'applicazione può memorizzare l'input maligno come se fosse uno statement SQL valido, ed un'altra parte dell'applicazione che non effettua controlli per proteggersi da SQL injections potrebbe eseguire lo statement memorizzato. Questo tipo di attacco richiede la conoscenza che i valori inviati vengano utilizzati successivamente. Gli scanner di sicurezza per applicazioni web potrebbero non accorgersi facilmente di questo tipo di SQL injection e potrebbero aver bisogno di essere istruite manualmente su dove cercare indizi sull'attacco.
Prevenzione L'SQL injection è un attacco molto conosciuto e facilmente evitabile con semplici misure. Dopo quello che si pensa fosse stato un attacco di SQL injection sull'azienda britannica TalkTalk Group, la BBC ha riportato come gli esperti di sicurezza fossero stupiti che una così grande compagnia fosse vulnerabile a questo tipo di attacco.
Statement parametrizzati Con molte delle piattaforme di sviluppo, è possibile usare statement parametrizzati che lavorano con dei parametri (chiamati placeholder o bind variable) al posto di inserire direttamente l'input dell'utente direttamente nello statement. Un placeholder può memorizzare soltanto un valore del tipo specificato e non un qualsiasi statement SQL. In questo modo l'SQL injection viene trattata semplicemente come un valore non valido per quel parametro.
In molti casi, lo statement SQL viene invece fissato, ed ogni parametro è quindi uno scalare, e non una tabella. L'input dell'utente è quindi assegnato (legato) ad un parametro.
Rafforzamento a livello di codice Usare delle librerie di object-relational mapping evita di scrivere codice SQL. Le librerie ORM generano automaticamente degli statement SQL parametrizzati, partendo da del codice orientato agli oggetti.
Escape Un modo diretto, anche se soggetto ad errori per prevenire attacchi di SQLI è quello di evitare caratteri che hanno un significato speciale in SQL. I manuali dei DBMS SQL spiegano quali caratteri hanno significati speciali, ciò permette di creare una lista di caratteri che devono essere sostituiti perché potenzialmente dannosi. Ad esempio, ogni apostrofo (') in un parametro deve essere sostituito con due apostrofi (' ') per ottenere una stringa SQL di letterali valida. Per esempio, in PHP di solito si evitano i caratteri speciali nei parametri utilizzando la funzione mysqli_real_escape_string(); prima di inviare la query SQL: $mysqli = new mysqli('hostname', 'db_username', 'db_password', 'db_name'); $query = sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND Password='%s'", $mysqli->real_escape_string($username), $mysqli->real_escape_string($password)); $mysqli->query($query);
Questa funzione antepone dei backslash ai seguenti caratteri: \x00, \n, \r, \, ', " e \x1a.