SQL Injection è una tecnica cyber criminale usata già da 25 anni per accedere ai database e rubare dati sensibili e informazioni preziose. Ecco cosa sapere e come ridurre il rischio di subirne le conseguenze


SQL injection è uno dei meccanismi di attacco informatico nel web più comuni utilizzati dagli aggressori per rubare dati sensibili dalle organizzazioni. È una tecnica ormai radicata, documentata per la prima volta nel 1998 e ancora oggi è un potenziale causa di rischio per molte attività. Negli anni ha fatto vittime illustri, da Adobe a Sony.

Nel rapporto annuale 2023 di Clusit sulla sicurezza ICT in Italia, SQL Injection risulta essere la prima tecnica di attacco applicativo contro i clienti Enterprise Fastweb – costituiti da grandi aziende e amministrazione pubblica nella stragrande maggioranza (50,75%) dei casi.

Per capire quanto si sia esposti a rischi il Computer Emergency Response Team dell’Agenzia per l’Italia Digitale (Cert-Agid) afferma che: “per l’utilizzatore di un sito web con una vulnerabilità SQLi ciò significa quasi sempre un furto di credenziali con conseguente furto di identità”.

SQL Injection si verifica quando cyber criminali inseriscono comandi o programmi dannosi (malware) nei moduli web, come il campo di ricerca, il campo di accesso o l’URL, di un sito web non sicuro, producendo danni potenzialmente molto gravi.

L’esempio di quanto accaduto ai danni della Heartland Payment Systems è significativo: a seguito di un attacco con SQL injection sono state compromesse 100 milioni di carte e violate più di 650 società di servizi finanziari con perdite comprovate per 300 milioni di dollari.

SQL Injection: cos’è?

Secondo la Cybersecurity & Infrastructure Security Agency statunitense, SQL Injection è una tecnica di attacco che tenta di sovvertire la relazione tra una pagina web e il relativo database di supporto, in genere per indurre il database a eseguire codice dannoso. Di solito comporta una combinazione di autorizzazioni eccessive e vulnerabilità del software (database).

I cyber delinquenti possono utilizzarla per inserire istruzioni SQL dannose nei campi di input per l’esecuzione da parte del database SQL sottostante.

SQL Injection è resa possibile dalla codifica impropria delle applicazioni web vulnerabili. Questi difetti sorgono perché i campi di immissione resi disponibili per l’input dell’utente consentono inaspettatamente alle istruzioni SQL di passare ed interrogare direttamente il database.

Gli aggressori sondano costantemente Internet e i siti web di imprese, enti, università e altre realtà alla ricerca di vulnerabilità SQL injection. Usano strumenti in grado di automatizzare la scoperta di difetti specifici e tentano di sfruttare questa tecnica malevola principalmente per guadagnare denaro ottenuto, per esempio, rubando informazioni di identificazione personale che vengono poi utilizzate per il furto di identità.

In atto ormai da 25 anni, SQL Injection è ancora un problema attuale. Il motivo è legato al fatto che molte applicazioni moderne sono basate sui dati e accessibili tramite il Web, le vulnerabilità SQL Injection sono diffuse e facilmente sfruttabili. Inoltre, a causa della prevalenza di infrastrutture di database condivise, un difetto SQL Injection in un’applicazione può portare alla compromissione di altre applicazioni che condividono la stessa istanza del database.

Una volta sfruttati, gli attacchi SQL Injection possono portare a furto, modifica o addirittura distruzione di dati sensibili come informazioni di identificazione personale, nomi utente e password. Inoltre gli aggressori possono sfruttare un server di database compromesso per attaccare altri sistemi sulla stessa rete.

Le categorie di SQL Injection

In genere, questi attacchi rientrano in tre categorie di SQLi: in banda (classico), inferenziale e fuori banda.

SQLi in banda

Definito anche SQL classico, si verifica quando gli hacker utilizzano lo stesso canale, o banda, per lanciare errori del database e raccogliere i risultati di un attacco. Questi errori costringono il database a produrre messaggi di errore che rivelano informazioni sulla struttura del database. SQL in banda può essere praticato con attacchi union-based, che utilizzano istruzioni preparate in grado di sfruttare la funzione di unione SQL, combinando i risultati di più query in un unico risultato.

SQL Injection inferenziale

Conosciuto anche come SQLi cieco, si verifica quando gli hacker malevoli inviano payload di dati a un server di database per osservarne la risposta e il comportamento senza essere in grado di vedere cosa sta accadendo all’interno del database. La risposta del server fornisce agli aggressori indizi che possono utilizzare per adattare la loro strategia di attacco.

Si manifesta in due forme: SQLi booleano e SQLi time-based. La prima si basa sull’invio di una query SQL al database che forza l’applicazione a restituire un risultato diverso a seconda che l’interrogazione restituisca un risultato vero o falso. La seconda si basa sull’invio di una query SQL al database che costringe il database ad attendere un periodo di tempo specificato (in secondi) prima di rispondere. Il tempo di risposta indicherà all’aggressore se il risultato della query è vero o falso.

SQLi fuori banda

Questo tipo di SQL injection avviene quando i cyber aggressori sfruttano il sistema dei nomi di dominio o le richieste del protocollo di trasferimento ipertestuale per recuperare dati. L’SQLi fuori banda viene eseguito solo quando un server Web è troppo lento o quando non è possibile eseguire SQLi in banda.

Esempi di SQL Injection

Esistono numerose vulnerabilità, attacchi e strategie di SQL injection che possono verificarsi in una varietà di contesti diversi.

Può accadere che i cyber aggressori usino una modifica della query SQL per recuperare dati nascosti, così da modificare una query SQL per rivelare informazioni aggiuntive. Oppure, per aggirare l’autenticazione e accedere al programma o al sito Web, possono inserire un comando SQL in un modulo di accesso. C’è anche il caso in cui alterano una query per ostacolare la logica dell’applicazione oppure per sferrare un “union attack” che permettono di recuperare dati da molte tabelle di database.

I criminali informatici di solito fanno un’accurata analisi della banca dati, per raccogliere informazioni sulla versione e struttura del database. Possono anche di mettere in pratica un attacco DDoS: in questo caso inseriscono un’istruzione SQL per generare un attacco Denial of Service o Distributed Denial of Service, travolgendo un sistema.

Per quanto riguarda esempi di attacchi avvenuti a danno di società famose, vale la pena segnalare qualche esempio. Uno dei più significativi che abbiamo già citato è stato messo in atto a spese della statunitense Heartland Payment Systems, nel 2008.

Nel 2011 a essere vittima di un SQL Injection è stata Sony Pictures, cui sono stati sottratti migliaia di documenti riservati, e-mail e film inediti. L’anno successivo Yahoo! Ha subito un attacco SQL Injection che ha provocato la violazione di 450mila credenziali utente.

Tra i più recenti e famosi va segnalato anche quello che ha colpito nel 2015 la società di telecomunicazioni britannica TalkTalk che ha subito una grave violazione con l’accesso ai dettagli di 157mila clienti, inclusi i numeri di conto bancario. La stessa società è stata multata con una pena pecuniaria di 400mila sterline. Nel 2020 a essere colpito è stato il database sanitario centrale estone. L’attacco ha potenzialmente compromesso le cartelle cliniche di quasi tutti i cittadini del Paese.

Le fasi di un attacco

Un attacco SQL injection viene attuato in varie fasi. Di solito ne vengono individuate sette che andiamo a illustrare.

  • 1) Ricognizione

Durante questa prima fase gli aggressori determinano informazioni sui loro obiettivi, punti deboli e vulnerabilità, raccogliendo dati da varie fonti, inclusi account di social media, registri pubblici e risultati dei motori di ricerca. Conoscere i punti deboli della vittima aiuta gli aggressori a concentrare i propri sforzi per lanciare un attacco efficace più velocemente e con meno sforzo. Comprendere quali tipi di dati sono archiviati su un sistema o un sito web determinerà quale tipo di codice dannoso viene utilizzato dagli aggressori contro il tuo sistema.

  • 2) Armamento

Una volta ottenute informazioni cruciali, avviene questa fase. Essa si verifica dopo che un utente malintenzionato ha identificato e sfruttato una vulnerabilità nel sistema. Durante questa fase, l’attaccante creerà payload dannosi (malware, script o codice dannoso) progettati per ottenere l’accesso a informazioni sensibili o interrompere le operazioni, puntando a bypassare le misure di sicurezza dell’organizzazione che intendono violare.

  • 3) Consegna

Comporta l’invio di codice o script dannosi a un sistema mirato per ottenere l’accesso non autorizzato. Gli aggressori possono utilizzare e-mail di phishing o siti web compromessi come vettori, ad esempio file JavaScript o documenti HTML contenenti codice dannoso. Questi payload includono istruzioni per sfruttare le applicazioni web vulnerabili sul sistema di destinazione e ottenere l’accesso a informazioni privilegiate. Durante le fasi di consegna, gli aggressori possono modificare le funzioni dell’applicazione esistente manipolando l’input dell’utente prima che l’applicazione lato server lo accetti.

  • 4) Sfruttamento

Una volta che l’attaccante ha ottenuto l’accesso al sistema di un’azienda, inizierà lo sfruttamento delle risorse. A seconda del tipo di informazioni che hanno ottenuto, possono assumere il controllo di interi database o addirittura di intere reti. Questo tipo di attività potrebbe consentire agli aggressori di assumere il controllo completo dell’infrastruttura IT e dei dati sensibili di un’organizzazione senza che nessuno se ne accorga finché non è troppo tardi.

  • 5) Installazione

Si verifica dopo che l’attaccante ha consegnato con successo il payload dannoso alla sua destinazione. Durante questa fase, gli aggressori in genere installano backdoor sui sistemi vulnerabili per mantenere l’accesso ed eseguire comandi aggiuntivi senza autorizzazione. Gli aggressori possono installare backdoor sfruttando vulnerabilità note o utilizzando credenziali compromesse. Gli attori delle minacce possono utilizzare queste backdoor per accedere a informazioni sensibili come password, numeri di carte di credito o altri dati riservati.

  • 6) Comando e controllo

La sesta fase avviene dopo che un utente malintenzionato ha ottenuto l’accesso a un sistema vulnerabile, ma non ha ancora lanciato i propri payload dannosi. Durante questa fase, un utente malintenzionato stabilirà un accesso remoto persistente e meccanismi per mantenere il controllo sul sistema compromesso, anche se viene riavviato o la sua connessione a Internet si interrompe temporaneamente. A questo punto, un utente malintenzionato può anche raccogliere più informazioni o distribuire file dannosi aggiuntivi per aiutarlo nella sua missione.

  • 7) Azioni sull’obiettivo

In questa fase finale gli aggressori in genere lanciano i loro payload dannosi e intraprendono le azioni desiderate. Ciò può includere l’accesso a dati sensibili, la modifica di configurazioni esistenti o l’esecuzione di comandi dannosi per ottenere un ulteriore accesso ad altri sistemi nella rete. Gli aggressori possono utilizzare il sistema compromesso come trampolino di lancio per eseguire attacchi DDoS contro altre reti o sistemi o utilizzare il sistema per archiviare dati rubati o ospitare codice dannoso. In questa fase, gli aggressori tenteranno probabilmente di coprire le proprie tracce cancellando qualsiasi prova del loro coinvolgimento. Dopo aver completato la loro missione, in genere si disconnetteranno dal punto di accesso remoto e cancelleranno ogni traccia delle loro attività.

Come prevenire gli attacchi SQL Injection

Gli attacchi SQL Injection, se messi a segno, causano danni ingenti. Per essere efficaci, gli attacchi hanno bisogno di contare su vulnerabilità di sistema causate da errori di programmazione e che i cyber delinquenti sfruttano abilmente. Per cercare di ridurre sensibilmente i rischi è possibile mettere in atto le seguenti precauzioni.

Istruzioni preparate

Le istruzioni preparate (prepared statements) rappresentano un metodo di protezione dagli attacchi SQL injection che permettono al programmatore di definire in anticipo una query parametrizzata, fornendo i dati da utilizzare nella query in fase di runtime. Il database separa i dati dalla query, consentendo di impedire che qualsiasi input dannoso venga interpretato come parte del comando SQL.

Procedura di archiviazione

Le stored procedure sono set precompilati di istruzioni SQL archiviate nel database richiamabili come una singola unità eseguibile. Quando viene attuata una procedura memorizzata, il database prima compila la procedura e poi esegue il codice compilato. Ciò significa che qualsiasi istruzione SQL dinamica all’interno della procedura memorizzata viene analizzata e ottimizzata solo una volta, quando la procedura memorizzata viene creata per la prima volta, anziché ogni volta che la procedura viene eseguita.

Le procedure memorizzate forniscono un ulteriore livello di sicurezza contro SQL Injection, poiché le istruzioni SQL all’interno della procedura memorizzata sono protette da manomissioni da parte degli utenti finali. Inoltre, possono applicare un insieme specifico di regole aziendali, riducendo il rischio che vengano eseguite istruzioni SQL non autorizzate.

Principio del privilegio minimo

Il principio del privilegio minimo (POLP – Principle of Least Privilege) ha alla base un concetto tanto semplice quanto efficace: gli utenti e i programmi dovrebbero disporre unicamente dei privilegi necessari per completare i loro compiti. Nello stesso modo, le applicazioni dovrebbero essere progettate per avere accesso solo alle risorse di cui hanno bisogno.

Nel contesto degli attacchi SQL injection, ciò significa limitare le autorizzazioni dell’applicazione quando interagisce con il database per ridurre il rischio che un utente malintenzionato utilizzi SQL injection per eseguire azioni dannose.

Convalida dell’input

La convalida dell’input di una lista consentita è un metodo di protezione che permette di verificare i dati di input per garantire che siano validi e consentiti. Questo approccio prevede la definizione di un insieme di input accettabili, noto anche come “lista consentita”, e l’accettazione solo dei dati che soddisfano i criteri di questa lista. Qualsiasi input che non corrisponde viene rifiutato.