SQL injection: cos'è, rischi e come prevenirla

La SQL injection è una vulnerabilità delle applicazioni che usano un database: un dato inserito dall'esterno, in un modulo, in un indirizzo web o in una chiamata API, finisce dentro un comando SQL e il database lo esegue come istruzione invece di trattarlo come semplice testo. Chi la sfrutta può leggere, modificare o cancellare dati e a volte superare il login. Si previene con le query parametrizzate, che tengono separati comandi e dati.

Qui la trattiamo dal punto di vista di chi gestisce un'azienda o un reparto IT, non di chi scrive il codice: dove si nasconde, come si previene e cosa chiedere a chi sviluppa o collauda il software.

Cos'è la SQL injection

Quasi tutte le applicazioni aziendali parlano con un database in SQL. Quando un utente cerca un cliente per codice, l'applicazione costruisce una richiesta che contiene quel codice. Il problema nasce se la richiesta si costruisce incollando il testo ricevuto dentro il comando.

Il catalogo delle debolezze del software gestito da MITRE classifica il difetto come CWE-89. Nella sua descrizione (resa nostra dall'inglese), il prodotto costruisce un comando SQL usando un input proveniente dall'esterno senza neutralizzare gli elementi speciali che possono modificarne il significato; il risultato è che l'input viene interpretato come SQL e non come dato dell'utente.

In pratica l'applicazione si fida del testo che riceve: un attaccante scrive nel campo qualcosa che il database legge come un ordine, e il database obbedisce con i permessi dell'applicazione. Basta un campo di ricerca, un parametro nell'indirizzo o un cookie.

La SQL injection fa parte di una famiglia più ampia, le injection, che comprende anche quelle verso i comandi del sistema operativo o verso altri interpreti. OWASP le tratta insieme nella stessa categoria.

Perché se ne parla ancora

Il difetto è noto da più di vent'anni e il rimedio pure. Eppure i dati lo tengono in cima alle classifiche:

• OWASP Top 10:2025. Nella classifica dei rischi delle applicazioni web la categoria A05:2025 Injection scende dal terzo al quinto posto, ma OWASP la descrive come una delle categorie più testate: il 100% delle applicazioni esaminate è stato provato per qualche forma di injection. Per la sola SQL injection i CVE registrati sono più di 14.000, con una frequenza bassa e un impatto alto.
• CWE Top 25 del 2025. La classifica MITRE delle debolezze più pericolose mette la CWE-89 al secondo posto, un gradino più su del 2024. Il calcolo si basa su 39.080 vulnerabilità pubblicate tra il 1° giugno 2024 e il 1° giugno 2025.
• CISA e FBI. Nel Secure by Design Alert del 25 marzo 2024 le due agenzie statunitensi ricordano che MySQL ha introdotto i prepared statements, la tecnica che elimina il difetto, nel 2004, e che la SQL injection è considerata una vulnerabilità unforgivable, imperdonabile, almeno dal 2007.

La ragione per cui resiste non è tecnica. Secondo lo stesso alert nasce dalla disattenzione degli sviluppatori alle buone pratiche, che mescolano le query al database con i dati forniti dagli utenti. È un problema di metodo di sviluppo, e quindi di governo del fornitore.

Cosa rischia un'azienda

La scheda CWE-89 elenca le conseguenze tipiche di una SQL injection sfruttata:

• lettura di dati riservati, perché i database contengono di solito le informazioni più sensibili: anagrafiche, ordini, dati personali, credenziali;
• modifica o cancellazione dei dati, con effetti sull'integrità che possono emergere settimane dopo;
• accesso come un altro utente senza conoscerne la password, se il login si appoggia a una query vulnerabile;
• modifica dei permessi, quando le informazioni di autorizzazione stanno nello stesso database;
• in alcuni casi esecuzione di comandi sul sistema, che porta l'attaccante oltre il database.

Un caso concreto: MOVEit Transfer

Un caso noto riguarda un software acquistato, non sviluppato in casa. Nell'advisory congiunto AA23-158A, FBI e CISA riportano che, secondo informazioni di fonte aperta, dal 27 maggio 2023 il gruppo ransomware CL0P ha sfruttato una SQL injection allora sconosciuta (CVE-2023-34362) in MOVEit Transfer, un software di trasferimento file di Progress Software. Sulle installazioni esposte su internet è stata installata una web shell, poi usata per sottrarre i dati dai database dell'applicazione.

Il rischio quindi non sta solo nel codice scritto in casa, ma in ogni applicazione esposta che interroga un database, compresa quella comprata.

Dove si nasconde in un'azienda del mid-market

• Software su misura scritto anni fa da un fornitore che oggi non c'è più, o da un collaboratore interno: portali clienti, configuratori, aree riservate per agenti e rivenditori.
• E-commerce e siti con plugin di terze parti, dove ogni componente aggiunto porta le sue query.
• Prodotti commerciali esposti, come il trasferimento file, i portali fornitori, le VPN con interfaccia web: qui la correzione dipende dal produttore e passa per il patch management.
• Reportistica e strumenti interni, dove l'utente sceglie colonne, filtri e ordinamenti. OWASP nota che i nomi di tabelle e colonne non si possono neutralizzare come i dati, e che è un problema comune nei software di reportistica.

Due false sicurezze ricorrenti, entrambe segnalate da OWASP. Usare un framework di accesso ai dati (un ORM) non basta se il codice concatena comunque l'input nelle query. E le stored procedure, le procedure salvate nel database, possono introdurre SQL injection se al loro interno costruiscono comandi dinamici con i dati ricevuti.

Come si previene

Le indicazioni di riferimento sono nel SQL Injection Prevention Cheat Sheet di OWASP e nell'alert CISA/FBI.

1. Query parametrizzate, come regola e non come eccezione

È la difesa primaria. Con le query parametrizzate (i prepared statements) il comando SQL viene definito per primo e i dati vengono passati dopo, separatamente: il database distingue sempre il codice dal dato, qualunque cosa scriva l'utente. CISA e FBI chiedono ai produttori di imporle su tutte le applicazioni, con librerie che rendano la strada sicura quella predefinita e controlli in fase di revisione del codice.

2. Liste di valori ammessi dove i parametri non bastano

Nomi di tabelle, colonne e criteri di ordinamento non si passano come parametri. Per questi OWASP indica la validazione con una lista di valori ammessi decisi nel codice, e definisce un sintomo di cattiva progettazione il fatto che l'utente scelga direttamente tabelle o colonne.

3. Il filtro dei caratteri non è una difesa

Ripulire o neutralizzare i caratteri speciali in ingresso è la strada che OWASP sconsiglia con più forza: è fragile e non garantisce di fermare tutte le injection. L'alert CISA la definisce difficile da applicare su larga scala e spesso aggirabile. Se un fornitore risponde che filtra gli apici, la risposta non è sufficiente.

4. Minimo privilegio sul database

Riduce il danno quando qualcosa sfugge. OWASP raccomanda di non dare mai all'applicazione un account amministrativo sul database, di usare utenti diversi per applicazioni diverse, di concedere la sola lettura dove serve solo leggere, e di non far girare il database con l'account più potente del sistema operativo.

5. Un WAF come strato in più

Un web application firewall riconosce e blocca molti tentativi di SQL injection dalla forma della richiesta, ed è utile per guadagnare tempo su un software che non si può correggere subito. Non elimina la vulnerabilità: la correzione nel codice resta da fare.

Come si trova prima che la trovi qualcun altro

Per OWASP il rilevamento funziona meglio combinando la revisione del codice sorgente con test automatici di tutti gli input: parametri, header, URL, cookie, dati JSON e XML. Inserire nella pipeline di sviluppo strumenti di analisi statica, dinamica e interattiva (SAST, DAST, IAST) aiuta a trovare i difetti prima del rilascio; le differenze tra i tre sono spiegate nell'articolo su SAST, DAST e SCA.

Gli strumenti automatici non bastano sulle parti autenticate e sulla logica dell'applicazione. Lì serve un web application penetration test, in cui un tester verifica in modo autorizzato se l'injection è sfruttabile e cosa permette di raggiungere. Come si inquadra un test di questo tipo, e cosa aspettarsi dal report, è nella guida al penetration test.

Cosa chiedere a chi sviluppa o fornisce il software

CISA e FBI invitano espressamente i clienti a chiedere ai fornitori se hanno fatto una revisione formale del codice per la SQL injection. Sono domande che può porre anche chi non scrive codice:

1. Usate query parametrizzate in tutta l'applicazione? Come lo imponete: librerie standard, controlli nella revisione del codice, analisi statica nella pipeline?
2. Avete fatto una revisione del codice mirata alla SQL injection? Quando, su quale versione, con quale esito?
3. Con quali permessi si collega l'applicazione al database? Se la risposta è un account amministratore, c'è un intervento da pianificare.
4. Quando è stato fatto l'ultimo test applicativo, da chi, e le vulnerabilità trovate sono state chiuse con un retest?
5. Come comunicate le vulnerabilità ai clienti? L'alert chiede ai produttori di pubblicarle tramite il programma CVE indicando la classe di debolezza (la CWE), così il cliente capisce dove le pratiche di sviluppo hanno un punto debole.

Meglio ancora se finiscono nei contratti e nei capitolati come requisiti scritti.

Cosa chiedono le norme

• NIS2. Il D.Lgs. 138/2024 non nomina la SQL injection, ma l'articolo 24, comma 2, lettera e), mette tra gli elementi minimi la sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, comprese la gestione e la divulgazione delle vulnerabilità.
• ISO/IEC 27001:2022. L'Annex A comprende i controlli 8.28 (codifica sicura), 8.29 (test di sicurezza in sviluppo e accettazione) e 8.30 (sviluppo affidato all'esterno), che valgono anche quando il codice lo scrive un fornitore.
• GDPR. Se dal database escono dati personali è una violazione da valutare: l'articolo 33 del Regolamento (UE) 2016/679 chiede di notificarla all'autorità di controllo (in Italia il Garante per la protezione dei dati personali) senza ingiustificato ritardo e, ove possibile, entro 72 ore da quando se ne è venuti a conoscenza, salvo che sia improbabile un rischio per le persone. Come prepararsi è nell'articolo sulla procedura di data breach.

Da dove partire

Il primo passo è un elenco: quali applicazioni esposte su internet interrogano un database, chi le ha scritte, chi le mantiene, quando sono state testate l'ultima volta. Da lì si decide dove servono domande al fornitore, dove un test e dove una correzione.

Resta il caso in cui il difetto c'è e nessuno lo sa ancora: in MOVEit la vulnerabilità era sconosciuta quando è stata sfruttata. In quella finestra conta accorgersi in fretta di richieste anomale al database e di estrazioni di dati fuori norma. AmagisTech lavora con il mid-market italiano su questo fronte, con un servizio di detection e response gestito: se vuoi capire cosa vedresti oggi di un attacco alle tue applicazioni web, trovi come lavoriamo nella pagina sulla cybersecurity gestita.