Advanced SAST: Detect dangerous SQL query construction, even if user input cannot be traced all the way to the sink to prove SQLi
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Problem
Note: this general problem is described in the parent epic, Advanced SAST: Report risky practices to improv... (&15649).
The specific instance of this problem is:
- A SQL query is manually constructed.
- It uses an insecure method of construction, such as string concatenation or format strings.
- In an effort to reduce false-positive results, Advanced SAST does not report this as a vulnerability unless the query string verifiably processes user input.
Proposal
Dangerous query construction is a risky practice, even when user input can't verifiably be traced to the query string.
We should report this type of risky practice as a vulnerability. However, we should avoid confusion with provable SQL injections by:
- Using a title that is distinct from the standard SQLi title, such as "Risky SQL query construction".
- Using a lower severity level than a verified SQLi.
- From first principles, one could argue that this is more of a confidence assessment than a severity assessment. But, it is also true that a verifiable user input path is a more severe and alert-worthy finding.
- Clearly explaining in the rule description that the rule flags risky query construction, and an injection vulnerability may or may not exist.
It seems that the most appropriate CWE is still CWE-89 SQL injection, since there isn't a "precursor" CWE that only covers the dangerous practice.
When a provable SQLi does exist, we should not also create this risky-query-construction vulnerability. Users would likely consider the second, less-severe finding to be unhelpful noise.