A03:2021 Injection

A03:2021 — Injection

Ref: https://owasp.org/Top10/A03_2021-Injection/

Common vulnerabilities in this category look like§

• User-supplied data is not validated, filtered, or sanitized by the application.
• Dynamic queries or non-parameterized calls without context-aware escaping are used directly in the interpreter.
• Hostile data is used within object-relational mapping (ORM) search parameters to extract additional, sensitive records.
• Hostile data is directly used or concatenated. The SQL or command contains the structure and malicious data in dynamic queries, commands, or stored procedures.

Defensive Design & Prevention§

• The preferred option is to use a safe API, which avoids using the interpreter entirely, provides a parameterized interface, or migrates to Object Relational Mapping Tools (ORMs).
  • Note: Even when parameterized, stored procedures can still introduce SQL injection if PL/SQL or T-SQL concatenates queries and data or executes hostile data with EXECUTE IMMEDIATE or exec().
• Use positive server-side input validation. This is not a complete defense as many applications require special characters, such as text areas or APIs for mobile applications.
• For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter.
  • Note: SQL structures such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names are dangerous. This is a common issue in report-writing software.
• Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.
• Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.