SQL injection

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.

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:

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:

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: