SQL injection vulnerabilities arise in applications where elements of a SQL query originate from an untrusted source. Without precautions, the untrusted data may maliciously alter the query, resulting in information leaks or data modification. The primary means of preventing SQL injection are sanitization and validation, which are typically implemented as parameterized queries and stored procedures.
Suppose a system authenticates users by issuing the following query to a SQL database. If the query returns any results, authentication succeeds; otherwise, authentication fails.
Suppose an attacker can substitute arbitrary strings for
<PASSWORD>. In that case, the authentication mechanism can be bypassed by supplying the following
<USERNAME> with an arbitrary password:
The authentication routine dynamically constructs the following query:
validuser is a valid user name, this
SELECT statement yields the
validuser record in the table. The password is never checked because
username='validuser' is true; consequently, the items after the
OR are not tested. As long as the components after the
OR generate a syntactically correct SQL expression, the attacker is granted the access of
Similarly, an attacker could supply the following string for
<PASSWORD> with an arbitrary username:
producing the following query:
'1'='1' always evaluates to true, causing the query to yield every row in the database. In this scenario, the attacker would be authenticated without needing a valid username or password.
Noncompliant Code Example
This noncompliant code example shows JDBC code to authenticate a user to a system. The password is passed as a
char array, the database connection is created, and then the passwords are hashed.
Unfortunately, this code example permits a SQL injection attack by incorporating the unsanitized input argument
username into the SQL command, allowing an attacker to inject
validuser' OR '1'='1. The
password argument cannot be used to attack this program because it is passed to the
hashPassword() function, which also sanitizes the input.
Noncompliant Code Example (
The JDBC library provides an API for building SQL commands that sanitize untrusted data. The
java.sql.PreparedStatement class properly escapes input strings, preventing SQL injection when used correctly. This code example modifies the
doPrivilegedAction() method to use a
PreparedStatement instead of
java.sql.Statement. However, the prepared statement still permits a SQL injection attack by incorporating the unsanitized input argument
username into the prepared statement.
Compliant Solution (
This compliant solution uses a parametric query with a
? character as a placeholder for the argument. This code also validates the length of the
username argument, preventing an attacker from submitting an arbitrarily long user name.
set*() methods of the
PreparedStatement class to enforce strong type checking. This technique mitigates the SQL injection vulnerability because the input is properly escaped by automatic entrapment within double quotes. Note that prepared statements must be used even with queries that insert data into the database.
Failure to sanitize user input before processing or storing it can result in injection attacks.
|The Checker Framework|
|Tainting Checker||Trust and security errors (see Chapter 8)|
SQL Injection (Java)
|CERT.IDS00.TDSQL||Protect against SQL injection|
CVE-2008-2370 describes a vulnerability in Apache Tomcat 4.1.0 through 4.1.37, 5.5.0 through 5.5.26, and 6.0.0 through 6.0.16. When a
RequestDispatcher is used, Tomcat performs path normalization before removing the query string from the URI, which allows remote attackers to conduct directory traversal attacks and read arbitrary files via a
.. (dot dot) in a request parameter.
|SEI CERT Perl Coding Standard||IDS33-PL. Sanitize untrusted data passed across a trust boundary|
CWE-116, Improper Encoding or Escaping of Output
Android Implementation Details
This rule uses Microsoft SQL Server as an example to show a database connection. However, on Android,
DatabaseHelper from SQLite is used for a database connection. Because Android apps may receive untrusted data via network connections, the rule is applicable.
IDS00-J. Prevent SQL Injection LiveLesson
Section 4.4.3, "Included If Validating"