Code injection: cos’è, come funziona e come prevenirla

La code injection è la tecnica di attacco con cui un malintenzionato inserisce codice proprio in un’applicazione, sfruttando input non validati, e glielo fa eseguire come se fosse parte del programma. È il capostipite di un’intera famiglia di attacchi — le falle di iniezione — che da sempre occupa i vertici della OWASP Top 10: quando l’iniezione riesce, l’attaccante non sta più “attaccando” l’applicazione dall’esterno, la sta programmando dall’interno.

In questo articolo vediamo come funziona una code injection, come si distingue dalle sue varianti (command injection, SQL injection, XSS), cosa rischia concretamente un’azienda e come prevenirla e verificarla.

1. Cos’è la code injection e come funziona
2. La famiglia injection: le varianti a confronto
3. L’impatto: dal plugin vulnerabile al controllo del server
4. Come prevenire la code injection
5. Come verificare se le vostre applicazioni sono vulnerabili

Cos’è la code injection e come funziona

Il meccanismo si regge su un equivoco che l’attaccante costruisce ad arte: l’applicazione si aspetta dati — un nome in un form, un parametro in un URL, un campo di ricerca — e riceve invece istruzioni, scritte nello stesso linguaggio in cui l’applicazione è sviluppata. Se l’input non viene validato e finisce in un punto del codice che lo interpreta ed esegue, quelle istruzioni diventano a tutti gli effetti parte del programma.

Il punto di forza della tecnica è la sua discrezione: la code injection non modifica il codice esistente — lo estende. L’applicazione continua a funzionare normalmente, e le funzionalità anomale introdotte dall’attaccante si mimetizzano nel comportamento legittimo: esfiltrare dati, creare accessi nascosti, ricontattare un server esterno per scaricare ulteriori componenti malevoli. È il motivo per cui queste compromissioni possono restare invisibili a lungo, e per cui la tecnica resta tra le più longeve e versatili nel repertorio degli attaccanti.

La famiglia injection: le varianti a confronto

“Injection” è una famiglia, non un singolo attacco: il principio è sempre lo stesso — input non fidato trattato come istruzione — ma cambia cosa viene iniettato e chi lo esegue:

La distinzione non è accademica: cambia il bersaglio finale e cambiano le difese. Della variante più diffusa contro gli utenti abbiamo parlato nell’approfondimento sull’attacco cross-site scripting, mentre sul fronte database abbiamo analizzato la SQL injection di tipo blind, la più subdola da individuare. La code injection in senso stretto è la variante più potente della famiglia: chi inietta codice nel linguaggio dell’applicazione può fare tutto ciò che l’applicazione può fare — e nei casi peggiori arrivare all’esecuzione di comandi arbitrari sul server, l’esito noto come remote code execution.

L’impatto: dal plugin vulnerabile al controllo del server

Il caso tipico nel tessuto aziendale italiano passa dai CMS: la stragrande maggioranza dei siti aziendali è costruita su piattaforme come WordPress arricchite di plugin — componenti pronti all’uso, sviluppati da terzi, con livelli di qualità molto variabili. Ogni plugin è codice che gira dentro il vostro sito: una falla di validazione in uno di essi è una falla del sito intero, ed episodi di vulnerabilità critiche in plugin diffusi su centinaia di migliaia di installazioni si ripetono ogni anno. Lo stesso vale per le API di terze parti da cui l’applicazione riceve dati: la fiducia nel fornitore non sostituisce la validazione di ciò che arriva.

Le conseguenze scalano con i privilegi del codice compromesso: dal furto dei dati gestiti dall’applicazione, alla manomissione dei contenuti, fino alla compromissione completa del server — che a quel punto può diventare punto d’appoggio per attacchi verso il resto della rete aziendale o verso i vostri stessi utenti, come avviene negli attacchi alla catena di distribuzione dei contenuti tipo web cache poisoning.

Come prevenire la code injection

La prevenzione vive nel codice e nella gestione. Sul primo fronte, la regola madre è la stessa di tutta la famiglia injection: nessun input è fidato — validazione rigorosa di formato e contenuto lato server, e mai, in nessun caso, input utente passato a funzioni che eseguono codice dinamicamente (le famiglie di funzioni tipo eval, che andrebbero considerate vietate salvo eccezioni motivate). A questo si aggiungono il principio del minimo privilegio — l’applicazione gira con i permessi minimi necessari, così che un’eventuale compromissione erediti poco — e l’analisi statica del codice durante lo sviluppo, di cui abbiamo parlato nell’approfondimento sul SAST, che riconosce proprio i pattern che rendono possibile l’iniezione.

Sul fronte gestionale: aggiornare tutto, sempre — CMS, plugin, librerie, framework. La maggior parte delle code injection reali non sfrutta falle sconosciute ma vulnerabilità note e già corrette, in installazioni che non hanno applicato la correzione. Un inventario dei componenti e un processo di aggiornamento disciplinato chiudono da soli la porta d’ingresso più usata.

Come verificare se le vostre applicazioni sono vulnerabili

Le falle di iniezione si prestano bene alla verifica strumentale sull’applicazione in esecuzione: gli strumenti di analisi dinamica sollecitano ogni punto di input con richieste costruite ad arte e osservano come l’applicazione risponde — l’approccio che abbiamo descritto nell’approfondimento sul Dynamic Application Security Testing, e che ha il pregio di testare l’applicazione reale, plugin e configurazioni comprese, senza bisogno del codice sorgente.

Il livello successivo è la verifica manuale: le iniezioni più insidiose emergono concatenando passaggi che gli strumenti automatici non collegano — un input apparentemente innocuo che attraversa più componenti prima di raggiungere il punto in cui viene eseguito, o una falla di iniezione usata come primo anello di una catena più lunga. È il lavoro dell’analista in un web application penetration testing: non solo trovare la falla, ma dimostrare fino a dove porterebbe.