SQL Injection: come funziona e come prevenirla

La SQL injection (o SQLi in breve) è uno dei trucchetti più vecchi nel manuale dell'hacker, ma è ancora incredibilmente comune e pericolosa. In poche parole, consiste nell'indurre un database a rivelare cose che non dovrebbe.

In questo articolo, ti spiegherò cos’è davvero la SQL injection, i diversi modi in cui gli attaccanti la usano, alcuni esempi reali che hanno causato danni seri e, cosa forse più importante, come puoi prevenirla. Che tu sia uno sviluppatore o semplicemente curioso di capire come si rompono le cose su internet, ne uscirai con una solida comprensione della SQLi (senza addormentarti a metà, promesso).

Che cos’è la SQL Injection? 

La SQL injection è un tipo di attacco che avviene quando qualcuno trova un modo per manipolare le query SQL che la tua app invia al database. Normalmente, quelle query servono per fare cose come recuperare il profilo di un utente o aggiornare una scheda prodotto. Ma con la SQLi, un attaccante può inserire parti di codice SQL malevolo nei campi di input (come barre di ricerca o form di login) e all’improvviso il database fa esattamente quello che lui vuole.

Perché funziona? 

Perché da qualche parte lungo la catena l’applicazione si fida un po’ troppo dell’input dell’utente e lo tratta come testo innocuo invece che come potenziale codice eseguibile. È come lasciare che qualcuno compili un modulo e poi incollare quello che ha scritto direttamente in una console di comando.

Perché è pericolosa?

La SQL injection è pericolosa perché può essere usata per visualizzare o rubare dati privati (come nomi utente, password o informazioni sulle carte di credito), bypassare le schermate di login, eliminare o modificare dati e, nei casi peggiori, prendere il controllo completo del server del database.

Quindi sì, la SQLi è una brutta storia, e non è nemmeno una preoccupazione recente in ambito sicurezza, ma ti sorprenderà vedere quante app non sono protette adeguatamente.

Tipi di SQL Injection

A seconda di come l’attaccante interagisce con la tua applicazione e del tipo di feedback che ottiene, la SQLi si presenta in alcune varianti. Ci sono 3 tipi principali con cui potresti imbatterti:

SQLi in-band

È il tipo più semplice. L’attaccante invia una query SQL malevola e ottiene i risultati direttamente dall’applicazione. È rapido e spesso molto efficace.

• SQLi basata su errori: Questa tecnica si basa sul fatto che il database restituisce utilmente messaggi di errore. Questi errori possono rivelare un sacco di informazioni utili, come i nomi delle tabelle o la struttura delle query, rendendo più facile per l’attaccante pianificare la mossa successiva.

• SQLi basata su UNION: Qui l’attaccante usa l’operatore UNION per combinare la propria query con quella che sta eseguendo la tua app. È un modo astuto per estrarre dati extra dal database e farli finire nella risposta.

SQLi inferenziale (detta anche Blind SQLi)

Questa è più subdola. Invece di vedere direttamente i risultati della query, l’attaccante osserva come si comporta l’applicazione per capire cosa succede sotto il cofano.

• SQLi basata su booleani (basata sul contenuto): L’attaccante modifica la query con condizioni vere o false (tipo 1=1 o 1=2) e osserva come cambia la pagina. Carica normalmente? Mostra un errore? Si comporta in modo strano?
• SQLi basata sul tempo: Questa tecnica aggiunge ritardi temporali nella query (ad es. WAITFOR DELAY '00:00:05') e usa il tempo di risposta per dedurre se una condizione è vera.

SQLi out-of-band (ovvero quando si fa i raffinati)

Questa è meno comune, ma vale la pena conoscerla. La SQLi out-of-band non si affida a risposte immediate dell’app. L’attaccante usa invece canali alternativi come richieste DNS o HTTP per estrarre dati. Di solito è usata quando non è possibile avere feedback diretto ma il server del database ha accesso a internet (e nel 90% dei casi, probabilmente non dovrebbe).

Tecniche comuni di SQL Injection

Ok, abbiamo visto i 3 tipi di SQL injection. Ma come fanno gli attaccanti, in pratica?

Attacco OR 1=1

Questo è un classico. Immagina un form di login dove devi inserire nome utente e password. Un attaccante potrebbe inserire qualcosa del genere:

' OR 1=1 --

La query SQL finisce per risultare così:

SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = '';

Dato che 1=1 è sempre vero, il database restituisce tutti gli utenti e -- trasforma il resto della query in un commento. Se non c’è un limite, l’attaccante potrebbe accedere senza nemmeno conoscere un nome utente valido.

Fonte: vmware

Comment injection

Come visto poco sopra, i caratteri -- o /* */ sono usati per commentare parti di un'istruzione SQL. Gli attaccanti li usano per rimuovere eventuali clausole extra che potrebbero rompere il payload iniettato. Per esempio, se non conoscono la struttura completa della query originale, possono troncarla e renderla di nuovo sintatticamente valida.

Istruzioni SQL a batch

Alcuni database permettono di eseguire più istruzioni SQL in una sola richiesta, separate da un punto e virgola. Questa funzione può essere sfruttata dagli hacker per fare di tutto, come modificare dati o persino eliminare tabelle se l’applicazione non lo limita.

'; DROP TABLE users; --

Attacchi basati su UNION

Iniettando un’istruzione UNION SELECT , gli attaccanti possono combinare la loro query malevola con quella legittima e recuperare risultati da altre tabelle come dati sensibili degli utenti, password o informazioni sulle carte di credito. In pratica, si sfrutta una query esistente per ottenere dati extra.

Blind SQL injection

L’abbiamo già menzionata. Anche quando l’app non mostra errori o non restituisce i risultati delle query, gli attaccanti possono comunque estrarre dati poco alla volta osservando il comportamento. È più lento e noioso, ma funziona. Spesso è automatizzato con strumenti che possono provare centinaia di query e risposte basate sul tempo.

SQL injection memorizzata

Il codice SQL malevolo viene salvato nel database, ad esempio in un profilo utente o in un commento, ed eseguito successivamente quando qualcuno visualizza quei dati.

Attacchi SQL Injection nel mondo reale

La SQL injection può sembrare roba di nicchia da hacker, ma nel corso degli anni ha causato danni molto concreti. E per danni intendo milioni di record esposti, multe salate e titoloni che non hanno fatto alcun favore ai reparti marketing.

Guess.com (2002)

Un esempio precoce che ha fatto drizzare le antenne. Un ricercatore di sicurezza ha sfruttato una falla di SQL injection e ha avuto accesso a oltre 200.000 record di clienti, inclusi dettagli delle carte di credito. La buona notizia è che è stata scoperta e segnalata da un hacker etico. 

Heartland Payment Systems (2009)

Una violazione enorme che ha colpito un processore di pagamenti: sono stati rubati oltre 130 milioni di numeri di carte di credito. Gli attaccanti hanno usato la SQL injection per ottenere un primo accesso, poi hanno scalato da lì. È spesso citata come una delle più grandi violazioni di dati di sempre.

Yahoo! Voices (2012)

Gli attaccanti hanno sfruttato una falla di SQL injection basata su UNION ed esposto 450.000 nomi utente e password in chiaro. Sì, hai letto bene: credenziali grezze archiviate in chiaro. Quella violazione è stata particolarmente imbarazzante perché Yahoo! era una grande azienda tech, e conservare password non crittografate era già allora un grave "no" anche secondo gli standard del 2012.

TalkTalk (2015)

TalkTalk, un importante operatore telecom nel Regno Unito, è caduto vittima di un attacco SQL injection piuttosto basilare. Circa 157.000 record di clienti sono stati compromessi e l’azienda è stata multata di £400.000. Uno degli attaccanti aveva solo 17 anni.

Gab (2021)

Attivisti hanno usato la SQL injection per esfiltrare 70 GB di dati, inclusi post privati e password con hash. La violazione aveva una forte connotazione politica e le conseguenze hanno portato a un’ancora maggiore attenzione sulla postura di sicurezza complessiva di Gab.

Come prevenire la SQL Injection

Ora che ci siamo un po’ spaventati con tutte queste violazioni reali, parliamo di soluzioni. La buona notizia è che prevenire la SQL injection non è scienza missilistica. Per lo più, si tratta di non fidarsi dell’input utente e attenersi alle buone pratiche. Ecco cosa puoi fare:

Usa query parametrizzate

È la regola numero uno. Non costruire mai query SQL incollando stringhe. Usa invece dei placeholder e passa gli input utente come parametri. La maggior parte dei framework e delle librerie lo rende facilissimo.

Per esempio, in Node.js con pg (PostgreSQL):

client.query('SELECT * FROM users WHERE id = $1', [userId]);

Di fatto stai dicendo al database: "Ecco la struttura della query, ed ecco dei dati: per favore non confonderli".

Usa le stored procedure in modo intelligente

Le stored procedure possono aiutare, ma solo se evitano anche l’SQL dinamico. L’idea è che la logica SQL viva nel database e che la tua app richiami solo quei blocchi di logica sicuri e predefiniti.

Se vuoi imparare a creare, aggiornare ed eseguire funzioni e stored procedure, dai un’occhiata al nostro corso Writing Functions and Stored Procedures in SQL Server.

Valida e sanitizza l’input

Se la tua app si aspetta un numero, assicurati che sia un numero. Non accettare alla cieca tutto ciò che un utente ti invia. Usa controlli di tipo, limiti di lunghezza e allowlist (ad es. consentire solo valori noti validi) quando possibile.

L’escape dei caratteri (come gli apici) può aiutare, ma non sostituisce le query parametrizzate.

Usa un Web Application Firewall (WAF)

Un WAF può fungere da prima linea di difesa, soprattutto contro pattern di attacco noti. Può aiutare a bloccare parte del traffico malevolo prima che raggiunga la tua app. Non è infallibile ma è utile, un po’ come un filtro antispam per il tuo SQL.

Applica il principio del privilegio minimo

La tua app web non dovrebbe connettersi al database con diritti di amministratore. Limita ciò che ogni utente o servizio può fare. Per esempio, se la tua app deve solo leggere i dati, non darle il permesso di eliminare tabelle. Meno potere ha, minori sono i danni che un’iniezione può causare.

Test e rilevamento della SQL Injection

Anche se pensi che il tuo codice sia sicuro, vale la pena testarlo come farebbe un attaccante. La SQL injection tende a infilarsi tra le crepe, soprattutto in codebase grandi o sistemi legacy. Ci sono strumenti e tecniche che rendono il rilevamento molto più semplice e anche piuttosto divertente da usare.

Test manuale

A volte il modo più rapido per scovare una falla è punzecchiarla. Prova a inserire ' OR 1=1 -- o '; DROP TABLE users; -- nei campi dei form, negli URL o in qualsiasi altra area di input e osserva come reagisce l’app. Se ottieni errori strani, dati inattesi o messaggi di successo misteriosi, potresti aver trovato qualcosa di sospetto.

Trucchetto: testa sempre in ambiente di sviluppo o staging. 

Scanner automatici

Esistono molti strumenti che faranno il lavoro di "punzecchiare" al posto tuo. Alcuni validi:

• sqlmap: Un mostro open-source che automatizza rilevamento e sfruttamento (in contesti di test etici).
• Burp Suite: Ottimo per la sicurezza delle web app in generale, con estensioni per il rilevamento di SQLi.
• OWASP ZAP: Gratuito e adatto ai principianti, pensato per trovare ogni tipo di vulnerabilità web.

Questi strumenti simulano attacchi, segnalano potenziali punti di iniezione e talvolta suggeriscono correzioni.

Analisi dei log

Un altro trucco utile: monitora i log del database. Query ripetute non riuscite, pattern di sintassi strani o un picco di richieste con ', --, o UNION SELECT sono tutti campanelli d’allarme.

Conclusione

La SQL injection non scomparirà presto, ed è una di quelle minacce che non invecchiano mai. È semplice, potente e, se non stai attento, può causare danni seri. Il punto è che la SQLi è totalmente prevenibile. Usando query parametrizzate, validando gli input, applicando il principio del privilegio minimo e testando regolarmente, puoi proteggere le tue applicazioni e i tuoi utenti dall’impatto devastante di un attacco di SQL injection. 

Ricorda, nessuno si aspetta la perfezione, ma con un po’ di impegno proattivo puoi tenere al sicuro il tuo database e depennare questa voce dalla tua checklist di sicurezza. E se prendi sul serio SQL e vuoi mostrare le tue competenze ai potenziali datori di lavoro, dai un’occhiata alla nostra SQL Associate Certification! Dimostrerà che sei in grado di usare SQL per estrarre i dati appropriati da un database e usarli per rispondere a domande comuni sui dati.