A03:2021 – Injection
Fattori
CWEs corrispondenti | Tasso di incidenza Max | Tasso di incidenza Medio | Sfruttabilità pesata | Impatto Medio | Copertura Max | Copertura media | Occorrenze Totali | CVE Totali |
---|---|---|---|---|---|---|---|---|
33 | 19.09% | 3.37% | 7.25 | 7.15 | 94.04% | 47.90% | 274,228 | 32,078 |
Panoramica
Injection scende alla terza posizione. Il 94% delle applicazioni sono state testate per qualche forma di injection con un tasso massimo di incidenza del 19%, un tasso medio di incidenza del 3% e 274k occorrenze. Le Common Weakness Enumerations (CWEs) incluse sono CWE-79: Cross-site Scripting, CWE-89: SQL Injection, and CWE-73: External Control of File Name or Path.
Descrizione
Un'applicazione è vulnerabile alle injection quando:
-
I dati forniti dall'utente non sono validati, filtrati o sanificati dall'applicazione.
-
Le query dinamiche o le chiamate non parametrizzate senza escaping contestuale vengono passate direttamente all'interprete.
-
Input malevolo viene usato all'interno di parametri di ricerca di un ORM (object-relational mapping) per estrarre ulteriori record sensibili.
-
Input malevolo viene usato in modo diretto o concatenato. Le query SQL o i comandi includono i dati ostili nelle query dinamiche, nei comandi o nelle stored procedure.
Alcune delle forme di injection più comuni sono SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP, e Expression Language (EL) o Object Graph Navigation Library (OGNL). Il concetto è identico tra tutti gli interpreti. La revisione del codice sorgente è il metodo migliore per rilevare se le applicazioni sono vulnerabili alle injection. È fortemente consigliato il testing automatico di tutti i parametri, headers, URL, cookie, e sui formati di dato come JSON, SOAP e XML. Le organizzazioni possono includere strumenti statici (SAST), dinamici (DAST) e interattivi (IAST) per i test di sicurezza delle applicazioni nella pipeline CI/CD per identificare prima della messa in produzione le problematiche di injection eventualmente presenti.
Come prevenire
Prevenire le forme di injection richiede di mantenere i dati separati dai comandi e dalle query:
-
L'opzione preferita è quella di usare un'API sicura, che eviti di usare l'interprete interamente, che fornisce un'interfaccia parametrizzata o migra verso strumenti di Object Relational Mapping (ORM).
Nota: Anche quando sono parametrizzate, le stored procedure possono ancora introdurre SQL injection se PL/SQL o T-SQL concatena query e dati o esegue input ostili con EXECUTE IMMEDIATE o exec(). -
Usare una validazione degli input lato server positiva. Questa non è una difesa completa, poiché molte applicazioni richiedono caratteri speciali, come aree di testo o API per applicazioni mobili.
-
Per qualsiasi query dinamica residua, svolgera l'escaping dei caratteri speciali usando la sintassi di escape specifica per quell'interprete.
Nota: Le strutture SQL come i nomi delle tabelle, i nomi delle colonne e così via non possono essere oggetto di escape, e quindi i nomi di queste strutture fornite dall'utente sono e rimangono pericolose. Questo è un problema comune nel software di reportistica. -
Usare LIMIT e altri controlli SQL all'interno delle query per prevenire la divulgazione di massa dei record in caso di SQL injection.
Esempi di scenari d'attacco
Scenario #1: Un'applicazione usa dati non fidati nella costruzione della seguente chiamata SQL vulnerabile:
String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'";
Scenario #2: Allo stesso modo, la fiducia cieca di un'applicazione nei framework può risultare in query che sono ancora vulnerabili, (ad esempio, Hibernate Query Language (HQL)):
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");
In entrambi i casi, l'attaccante modifica il valore del parametro 'id' nel suo browser per inviare: ' UNION SELECT SLEEP(10);--. Per esempio:
http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);--
Questo cambia il significato di entrambe le query per restituire tutti i record dalla della tabella degli account. Attacchi più pericolosi potrebbero modificare o cancellare i dati o anche invocare stored procedures.
Riferimenti
Lista dei CWE correlati
CWE-20 Improper Input Validation
CWE-75 Failure to Sanitize Special Elements into a Different Plane (Special Element Injection)
CWE-77 Improper Neutralization of Special Elements used in a Command ('Command Injection')
CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
CWE-80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
CWE-83 Improper Neutralization of Script in Attributes in a Web Page
CWE-87 Improper Neutralization of Alternate XSS Syntax
CWE-88 Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')
CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
CWE-90 Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
CWE-91 XML Injection (aka Blind XPath Injection)
CWE-93 Improper Neutralization of CRLF Sequences ('CRLF Injection')
CWE-94 Improper Control of Generation of Code ('Code Injection')
CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
CWE-96 Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')
CWE-97 Improper Neutralization of Server-Side Includes (SSI) Within a Web Page
CWE-99 Improper Control of Resource Identifiers ('Resource Injection')
CWE-100 Deprecated: Was catch-all for input validation issues
CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')
CWE-116 Improper Encoding or Escaping of Output
CWE-138 Improper Neutralization of Special Elements
CWE-184 Incomplete List of Disallowed Inputs
CWE-470 Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
CWE-471 Modification of Assumed-Immutable Data (MAID)
CWE-564 SQL Injection: Hibernate
CWE-610 Externally Controlled Reference to a Resource in Another Sphere
CWE-643 Improper Neutralization of Data within XPath Expressions ('XPath Injection')
CWE-644 Improper Neutralization of HTTP Headers for Scripting Syntax
CWE-652 Improper Neutralization of Data within XQuery Expressions ('XQuery Injection')
[CWE-917 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')] (https://cwe.mitre.org/data/definitions/917.html)