Una delle più usate tecniche d’attacco per sottrarre informazioni e dati ad aziende e PA, le SQL Injection sfruttano falle dei sistemi, ma possono essere affrontate. Ecco come
La fame di dati e informazioni sensibili porta i criminali informatici a usare la SQL Injection, tra le più diffuse minacce usate per minare la cybersecurity delle aziende e non solo. SQLi è un incubo per le aziende, grandi o piccole, e per enti pubblici, data la diffusione di database in ogni settore. Statista segnala che rappresenta la principale fonte di vulnerabilità critiche delle applicazioni web rilevate a livello globale nel 2022, con il 33%.
Si tratta di una tecnica d’attacco diretto impiegata da hacker malevoli per accedere ai dati, sfruttando le debolezze del linguaggio di programmazione per la gestione dei database. Più precisamente, è usata per ottenere l’accesso non autorizzato al database di un’applicazione web aggiungendo una stringa di codice dannoso a una query della banca dati.
Il CLUSIT, nel proprio report 2023 sulla sicurezza ICT in Italia registra che SQL Injection è il principale tentativo di attacco applicativo, in termini di utilizzo, ai software dei dispositivi e diretti contro i clienti Enterprise Fastweb (grandi aziende e PA). Primo per ampio distacco: il 50,75% degli attacchi rivolti a imprese di grandi dimensioni e pubblica amministrazione è costituito proprio da SQLi.
Cos’è l’SQL Injection
Detto che la Structured Query Language è il linguaggio di programmazione per memorizzare ed elaborare le informazioni in un database relazionale, la SQL Injection è una tecnica usata per ottenere l’accesso non autorizzato al database di un’applicazione web posizionando codice dannoso nelle istruzioni SQL, tramite l’input della pagina web. In pratica la SQLi manipola il codice SQL per fornire accesso a risorse protette, come dati sensibili, o eseguire istruzioni SQL dannose. Se eseguita correttamente, questa tecnica di attacco può esporre la proprietà intellettuale, i dati dei clienti o le credenziali amministrative di un’azienda privata. Proprio così: usando SQL Injection è possibile accedere a informazioni sensibili come indirizzi e-mail, nomi utente, password e dettagli della carta di credito archiviati nel database. Ciò significa che non solo un utente malintenzionato può leggere queste informazioni, ma può anche modificarle o eliminarle.
In genere, questi attacchi rientrano in tre categorie di SQLi: in banda (classico), inferenziale e fuori banda.
SQLi in banda (SQLi classico)
In-band SQL Injection è il più comune e facile da sfruttare degli attacchi SQL Injection. Si verifica quando un utente malintenzionato è in grado di utilizzare lo stesso canale di comunicazione sia per lanciare l’attacco che per ottenere risultati.
Le due varianti più comuni di SQL Injection in banda sono SQLi basato su errori e SQLi basato su unione. La prima è incentrata sui messaggi di errore lanciati dal server del database per ottenere informazioni sulla struttura del database. In alcuni casi, la sola error-based SQLi è sufficiente per consentire a un utente malintenzionato di enumerare un intero database.
La seconda sfrutta l’operatore UNION SQL per combinare i risultati di due o più istruzioni SELECT in un unico risultato che viene quindi restituito come parte della risposta HTTP.
SQLi inferenziale (detto anche Blind SQL Injection)
L’Inferential SQL Injection, a differenza di quella in banda, può richiedere più tempo per essere sfruttato da un cyber criminale, tuttavia, è molto pericoloso. Con questo tipo di minaccia è possibile ricostruire la struttura del database inviando payload, osservando la risposta dell’applicazione web e il comportamento risultante del server del database.
Questo tipo di SQL Injection si manifesta sotto due sottovarianti: SQLi booleano e SQLi basato sul tempo. 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
È una tecnica SQL Injection non molto comune perché dipende dalle funzionalità abilitate sul server di database utilizzato dall’applicazione web. Essa si verifica quando un utente malintenzionato non è in grado di utilizzare lo stesso canale per lanciare l’attacco e raccogliere i risultati. Le tecniche fuori banda offrono all’aggressore un’alternativa alle tecniche inferenziali basate sul tempo, soprattutto se le risposte del server non sono molto stabili.
Chi è a rischio
Come mette in luce il CLUSIT, grandi aziende e amministrazione pubblica sono attaccati principalmente mediante SQL Injection. Ma non sono certo le uniche: solo i database NoSQL sono sono esenti da questa tecnica d’attacco (e dalle sue varianti). SQL Injection può essere utilizzata per prendere di mira qualsiasi applicazione che utilizza un database SQL, inclusi MySQL, Oracle e SQL Server.
Secondo l’Open web Application Security Project, gli attacchi Injection, che includono SQLi, sono stati il terzo più grave rischio per la sicurezza delle applicazioni web nel 2021.
I ricercatori di sicurezza informatica considerano l’SQLi come uno dei meno sofisticati e facili da affrontare tra le minacce informatiche, in quanto è un attacco noto e prevedibile con contromisure facilmente implementabili. Eppure è molto diffuso: i tecnici di Malwarebytes Labs hanno classificato SQLi al terzo posto tra le cinque minacce informatiche più “sciocche”, ma che funzionano comunque. I cyber aggressori possono trovare siti web vulnerabili utilizzando specifiche ricerche Google avanzate, chiamate Google Dorks.
Le fasi di un attacco
Sono sette le fasi in cui si compone una SQL Injection.
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 le SQL Injection
Rilevare e prevenire gli attacchi SQLi è fondamentale per mantenere la sicurezza e l’integrità delle applicazioni web.
Occorre mantenere aggiornati tutti i componenti software dell’applicazione web, inclusi librerie, plug-in, framework, software del server web e software del server di database con le patch di sicurezza più recenti disponibili dai fornitori.
Per proteggere le applicazioni web, tutti coloro che sono coinvolti nella creazione dell’applicazione web devono essere consci dei rischi associati alle SQL Injection. Per questo serve consapevolezza e formazione adeguata. Altro principio da considerare è quello di non utilizzare account di database condivisi tra diversi siti web o applicazioni.
Occorre applicare il principio zero trust, ovvero non fidarsi di alcun input dell’utente. Significa che occorre considerare tutti gli input dell’utente come non attendibili. Qualsiasi input dell’utente utilizzato in una query SQL introduce il rischio di una SQL Injection.
Le SQLi possono essere introdotte da sviluppatori o tramite librerie, moduli, software esterni. È bene monitorare regolarmente le applicazioni web usando strumenti dedicati, come web security scanner.
