SQL injection e command injection

La SQL injection (SQLi) si verifica quando un attaccante inserisce o «inietta» codice SQL dannoso in un campo di input che viene successivamente passato a una query del database. Poiché l'applicazione concatena direttamente l'input dell'utente in un'istruzione SQL, il database non è in grado di distinguere tra dati legittimi e comandi forniti dall'attaccante. La SQLi si colloca costantemente tra le vulnerabilità web più pericolose della OWASP Top 10.

Una query di accesso vulnerabile potrebbe essere simile a: SELECT * FROM users WHERE username='INPUT' AND password='INPUT'. Se un attaccante fornisce ' OR '1'='1 come nome utente, la query viene trasformata in modo che la clausola WHERE risulti sempre vera, aggirando completamente l'autenticazione. Questo è il classico caso di iniezione basata su tautologia.

Gli attacchi di SQL injection possono assumere diverse forme: la SQLi in-band restituisce i risultati direttamente nella risposta HTTP (basata su errori o su UNION). La Blind SQLi ricava informazioni tramite risposte booleane vero/falso o ritardi temporali intenzionali (SLEEP(5)). La SQLi out-of-band utilizza canali secondari, come le richieste DNS, per esfiltrare dati quando le risposte non sono visibili.

La difesa principale contro la SQL injection consiste nell'utilizzare query parametrizzate (chiamate anche prepared statement). In una query parametrizzata, la struttura SQL viene compilata prima e l'input dell'utente viene passato come parametro separato: non può mai modificare la struttura della query. Questo approccio è indipendente dal linguaggio ed è molto più affidabile della sola sanitizzazione dell'input.

Sebbene le query parametrizzate siano la difesa principale, la validazione dell'input fornisce un importante livello secondario. La validazione tramite allowlist accetta solo i caratteri previsti (ad esempio, esclusivamente caratteri alfanumerici per un campo del nome utente) e rifiuta tutto il resto. La validazione tramite denylist blocca i caratteri noti come dannosi, ma gli attaccanti spesso codificano o offuscano i payload per aggirare le denylist: per questo le allowlist sono molto più efficaci.

La command injection (iniezione di comandi OS) si verifica quando un'applicazione passa input utente non sanitizzato a una shell di sistema. A differenza della SQL injection, che prende di mira i database, la command injection prende di mira direttamente il sistema operativo, dando agli attaccanti la possibilità di eseguire comandi arbitrari con i privilegi del processo del server web. Ha una gravità classificata come critica e spesso porta alla compromissione completa del sistema.

Un'applicazione web che esegue il ping di un indirizzo IP fornito dall'utente potrebbe utilizzare: ping -c 1 INPUT. Se un attaccante fornisce 8.8.8.8; cat /etc/passwd, la shell interpreta ; come separatore di comandi ed esegue entrambi i comandi. Tra gli operatori di injection più comuni vi sono ;, &&, ||, | e la sostituzione di comandi tramite backtick.

La difesa più sicura contro la command injection consiste nell'evitare completamente di chiamare comandi del sistema operativo a partire dall'input dell'utente e utilizzare invece funzioni di libreria che raggiungano lo stesso obiettivo. Quando le chiamate alla shell sono inevitabili, passi gli argomenti come elenco (mai come stringa concatenata), disabiliti l'interpretazione della shell, convalidi l'input rispetto a una allowlist rigorosa ed esegua i processi con l'account utente dotato del privilegio minimo possibile.

La OWASP Top 10 elenca Injection (che comprende le injection SQL, NoSQL, OS e LDAP) tra i rischi più critici per la sicurezza delle applicazioni. OWASP raccomanda un approccio di difesa in profondità: utilizzate API sicure che evitino l'interprete, eseguite la convalida positiva degli input (allowlist) lato server, effettuate l'escape dei caratteri speciali utilizzando la sintassi specifica dell'interprete e usate controlli SQL come LIMIT per impedire la divulgazione massiva dei dati.

Un Web Application Firewall (WAF) può rilevare e bloccare i payload di injection comuni analizzando le richieste HTTP e confrontandole con pattern di firma. Tuttavia, i WAF possono essere aggirati tramite tecniche di encoding e non sostituiscono una programmazione sicura. Un logging corretto dell'applicazione — che registri i parametri delle query, i codici di risposta e i messaggi di errore — consente ai team di sicurezza di identificare i tentativi di injection durante l'analisi degli incidenti.

Gli attacchi di injection hanno causato alcune delle più grandi violazioni dei dati della storia. La violazione di Equifax del 2017 ha esposto 147 milioni di record tramite una vulnerabilità di un'applicazione web. Un attacco SQL injection contro PlayStation Network di Sony ha compromesso 77 milioni di account nel 2011. Questi incidenti dimostrano che le vulnerabilità di injection hanno un impatto aziendale estremo: dal furto di dati alle sanzioni normative, fino al danno reputazionale e alla responsabilità legale, tutte queste conseguenze possono derivare da un attacco di injection riuscito.

Verificate la vostra comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

In questa lezione avete appreso che: SQL injection sfrutta input non sanificati concatenati nelle query al database, la command injection passa input dannosi alla shell del sistema operativo tramite operatori come ; e | e le query parametrizzate e l'evitare shell=True sono le principali difese. Ora esamineremo gli attacchi Cross-Site Scripting (XSS) e CSRF.