A05:2025 Injection

Contesto.

L'Injection scende di due posizioni dal #3 al #5 nella classifica, mantenendo la sua posizione relativa rispetto ad A04:2025-Cryptographic Failures e A06:2025-Insecure Design. L'Injection è una delle categorie più testate, con il 100% delle applicazioni testate per qualche forma di injection. Ha avuto il maggior numero di CVE per qualsiasi categoria, con 37 CWE in questa categoria. L'Injection include Cross-site Scripting (alta frequenza/basso impatto) con oltre 30k CVE e SQL Injection (bassa frequenza/alto impatto) con oltre 14k CVE. Il numero massivo di CVE segnalati per CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') abbassa l'impatto medio ponderato di questa categoria.

Tabella dei punteggi.

CWE Mappate	Tasso Massimo di Incidenza	Tasso Medio di Incidenza	Copertura Massima	Copertura Media	Exploit Medio Ponderato	Impatto Medio Ponderato	Totale Occorrenze	Totale CVE
37	13,77%	3,08%	100,00%	42,93%	7,15	4,32	1.404.249	62.445

Descrizione.

Una vulnerabilità di injection è una falla applicativa che consente all'input non attendibile dell'utente di essere inviato a un interprete (es. un browser, un database, la riga di comando) e fa sì che l'interprete esegua parti di quell'input come comandi.

Un'applicazione è vulnerabile agli attacchi quando:

I dati forniti dall'utente non vengono validati, filtrati o sanificati dall'applicazione.
Query dinamiche o chiamate non parametrizzate senza escape consapevole del contesto vengono utilizzate direttamente nell'interprete.
Dati non sanificati vengono utilizzati nei parametri di ricerca dell'object-relational mapping (ORM) per estrarre record aggiuntivi e sensibili.
Dati potenzialmente ostili vengono direttamente utilizzati o concatenati. L'SQL o il comando contiene la struttura e i dati malevoli in query dinamiche, comandi o stored procedure.

Alcune delle injection più comuni sono SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP e Expression Language (EL) o Object Graph Navigation Library (OGNL) injection. Il concetto è identico tra tutti gli interpreti. Il rilevamento è meglio ottenuto tramite una combinazione di revisione del codice sorgente e testing automatizzato (incluso il fuzzing) di tutti i parametri, header, URL, cookie, dati JSON, SOAP e XML. L'aggiunta di strumenti di testing della sicurezza applicativa statici (SAST), dinamici (DAST) e interattivi (IAST) nella pipeline CI/CD può essere utile per identificare le falle di injection prima della distribuzione in produzione.

Una classe correlata di vulnerabilità di injection è diventata comune negli LLM. Queste sono discusse separatamente nell'OWASP LLM Top 10, specificamente LLM01:2025 Prompt Injection.

Come prevenire.

Il modo migliore per prevenire l'injection richiede di mantenere i dati separati dai comandi e dalle query:

L'opzione preferita è utilizzare un'API sicura, che eviti l'uso dell'interprete interamente, fornisca un'interfaccia parametrizzata, o migri verso Object Relational Mapping Tools (ORM). Nota: Anche quando parametrizzate, le stored procedure possono ancora introdurre SQL injection se PL/SQL o T-SQL concatena query e dati o esegue dati ostili con EXECUTE IMMEDIATE o exec().

Quando non è possibile separare i dati dai comandi, è possibile ridurre le minacce utilizzando le seguenti tecniche.

Utilizzare la validazione degli input positiva lato server. Non si tratta di una difesa completa poiché molte applicazioni richiedono caratteri speciali, come aree di testo o API per applicazioni mobile.
Per qualsiasi query dinamica residua, eseguire l'escape dei caratteri speciali utilizzando la sintassi di escape specifica per quell'interprete. Nota: Le strutture SQL come i nomi delle tabelle, i nomi delle colonne, ecc. non possono essere sottoposte a escape, quindi i nomi di struttura forniti dall'utente sono pericolosi. Questo è un problema comune nel software di generazione di report.

Attenzione: queste tecniche implicano l'analisi e l'escape di stringhe complesse, rendendole soggette a errori e non robuste a fronte di piccole modifiche al sistema sottostante.

Scenari di attacco di esempio.

Scenario #1: Un'applicazione utilizza dati non attendibili nella costruzione della seguente chiamata SQL vulnerabile:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Un attaccante modifica il valore del parametro 'id' nel browser inviando: ' OR '1'='1. Ad esempio:

http://example.com/app/accountView?id=' OR '1'='1

Questo modifica il significato della query per restituire tutti i record dalla tabella degli account. Attacchi più pericolosi potrebbero modificare o eliminare dati o persino invocare stored procedure.

Scenario #2: L'eccessiva fiducia di un'applicazione nei framework può risultare in query ancora vulnerabili. Ad esempio, Hibernate Query Language (HQL):

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

Un attaccante fornisce: ' OR custID IS NOT NULL OR custID='. Questo bypassa il filtro e restituisce tutti gli account. Sebbene HQL abbia meno funzioni pericolose del SQL grezzo, consente ancora l'accesso non autorizzato ai dati quando l'input dell'utente viene concatenato nelle query.

Scenario #3: Un'applicazione passa direttamente l'input dell'utente a un comando OS:

String cmd = "nslookup " + request.getParameter("domain");
Runtime.getRuntime().exec(cmd);

Un attaccante fornisce example.com; cat /etc/passwd per eseguire comandi arbitrari sul server.