203
Automated Static Analysis
This weakness can often be detected using automated static analysis tools. Many modern tools
use data flow analysis or constraint-based techniques to minimize the number of false positives.
Automated static analysis might not be able to recognize when proper input validation is being
performed, leading to false positives - i.e., warnings that do not have any security consequences
or do not require any code changes. Automated static analysis might not be able to detect the
usage of custom API functions or third-party libraries that indirectly invoke SQL commands,
leading to false negatives - especially if the API/library code is not available for analysis.
Automated Dynamic Analysis
This weakness can be detected using dynamic tools and techniques that interact with the
software using large test suites with many diverse inputs, such as fuzz testing (fuzzing),
robustness testing, and fault injection. The software's operation may slow down, but it should not
become unstable, crash, or generate incorrect results.
Effectiveness = Moderate
Manual Analysis
Manual analysis can be useful for finding this weakness, but it might not achieve desired code
coverage within limited time constraints. This becomes difficult for weaknesses that must be
considered for all inputs, since the attack surface can be too large.
Automated Static Analysis - Binary or Bytecode
According to SOAR, the following detection techniques may be useful: Highly cost effective:
Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary
Weakness Analysis - including disassembler + source code weakness analysis
Effectiveness = High
Dynamic Analysis with Automated Results Interpretation
According to SOAR, the following detection techniques may be useful: Highly cost effective:
Database Scanners Cost effective for partial coverage: Web Application Scanner Web Services
Scanner
Effectiveness = High
Dynamic Analysis with Manual Results Interpretation
According to SOAR, the following detection techniques may be useful: Cost effective for partial
coverage: Fuzz Tester Framework-based Fuzzer
Effectiveness = SOAR Partial
Manual Static Analysis - Source Code
According to SOAR, the following detection techniques may be useful: Highly cost effective:
Manual Source Code Review (not inspections) Cost effective for partial coverage: Focused
Manual Spotcheck - Focused manual analysis of source
Effectiveness = High
Automated Static Analysis - Source Code
According to SOAR, the following detection techniques may be useful: Highly cost effective:
Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer
Effectiveness = High
Architecture or Design Review
According to SOAR, the following detection techniques may be useful: Highly cost effective:
Formal Methods / Correct-By-Construction Cost effective for partial coverage: Inspection (IEEE
1028 standard) (can apply to requirements, design, source code, etc.)
CWE Version 4.14
CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
CWE-89: Improper Neutralization of Special
Elements used in an SQL Command ('SQL Injection') 204
Effectiveness = High
Potential Mitigations
Phase: Architecture and Design
Strategy = Libraries or Frameworks
Use a vetted library or framework that does not allow this weakness to occur or provides
constructs that make this weakness easier to avoid. For example, consider using persistence
layers such as Hibernate or Enterprise Java Beans, which can provide significant protection
against SQL injection if used properly.
Phase: Architecture and Design
Strategy = Parameterization
If available, use structured mechanisms that automatically enforce the separation between
data and code. These mechanisms may be able to provide the relevant quoting, encoding,
and validation automatically, instead of relying on the developer to provide this capability at
every point where output is generated. Process SQL queries using prepared statements,
parameterized queries, or stored procedures. These features should accept parameters or
variables and support strong typing. Do not dynamically construct and execute query strings
within these features using "exec" or similar functionality, since this may re-introduce the
possibility of SQL injection. [REF-867]
Phase: Architecture and Design
Phase: Operation
Strategy = Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks
[REF-76]. If possible, create isolated accounts with limited privileges that are only used for a
single task. That way, a successful attack will not immediately give the attacker access to the
rest of the software or its environment. For example, database applications rarely need to run as
the database administrator, especially in day-to-day operations. Specifically, follow the principle
of least privilege when creating user accounts to a SQL database. The database users should
only have the minimum privileges necessary to use their account. If the requirements of the
system indicate that a user can read and modify their own data, then limit their privileges so they
cannot read/write others' data. Use the strictest permissions possible on all database objects,
such as execute-only for stored procedures.
Phase: Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are
duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side
checks by modifying values after the checks have been performed, or by changing the client to
remove the client-side checks entirely. Then, these modified values would be submitted to the
server.
Phase: Implementation
Strategy = Output Encoding
While it is risky to use dynamically-generated query strings, code, or commands that mix control
and data together, sometimes it may be unavoidable. Properly quote arguments and escape
any special characters within those arguments. The most conservative approach is to escape
or filter all characters that do not pass an extremely strict allowlist (such as everything that is
not alphanumeric or white space). If some special characters are still needed, such as white
space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument
injection (CWE-88). Instead of building a new implementation, such features may be available
in the database or programming language. For example, the Oracle DBMS_ASSERT package
can check or enforce that parameters have certain properties that make them less vulnerable to
CWE Version 4.14
CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
CWE-89: Improper Neutralization of Special
Elements used in an SQL Command ('SQL Injection')