logo

Database

Description

Dynamic SQL statements are built by concatenating untrusted input (from query parameters, HTTP headers, or other request fields) without the required data validation and without using parameterized statements, prepared statements, or stored procedures free of internal concatenation. This also includes ORM-based query languages (e.g., JPQL, HQL), expression bindings (e.g., SpEL) that evaluate attacker-controlled values as part of the query, and dynamic identifiers (table names, column names, sort order) built from untrusted input, which parameterized statements alone cannot protect.

Impact

Inject SQL statements, with the possibility of obtaining, modifying, or deleting information from the database.

Recommendation

- Perform database queries through parameterized statements or prepared statements instead of string concatenation. A stored procedure is only safe if it does not itself build dynamic SQL by concatenating its parameters (e.g., via 'sp_executesql' or 'EXEC'); used that way, it is just as injectable as inline concatenation. - Parameters cannot be used for dynamic identifiers (table names, column names, 'ORDER BY' direction); validate these against a strict allow-list of expected values instead. - When using LIKE-conditions with user-supplied values, sanitize wildcard characters explicitly (e.g., using the escape(String) function); parameterization alone does not prevent wildcard injection in LIKE clauses. - Run database queries with a least-privilege account scoped to only the operations and tables the application needs, to limit the impact of any injection that does occur.

Threat

Authenticated attacker from the Internet.

Expected Remediation Time

⏱️ 30 minutes.