| Common Consequences | Confidentiality: Since SQL databases generally hold sensitive data, loss of
confidentiality is a frequent problem with SQL injection vulnerabilities. Authentication: If poor SQL commands are used to check user names and
passwords, it may be possible to connect to a system as another user with no previous
knowledge of the password. Authorization: If authorization information is held in a SQL database, it may
be possible to change this information through the successful exploitation of a SQL injection
vulnerability. Integrity: Just as it may be possible to read sensitive information, it is
also possible to make changes or even delete this information with a SQL injection
attack. |
| Potential Mitigations | Requirements specification: A non-SQL style database which is not subject to this flaw
may be chosen. Design: Follow the principle of least privilege when creating user accounts to a SQL
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. Design: Duplicate any filtering done on the client-side on the server side. Implementation: Implement SQL strings using prepared statements that bind variables.
Prepared statements that do not bind variables can be vulnerable to attack. Implementation: Use vigorous white-list style checking on any user input that may be
used in a SQL command. Rather than escape meta-characters, it is safest to disallow them
entirely. Reason: Later use of data that have been entered in the database may neglect to
escape meta-characters before use. Narrowly define the set of safe characters based on the
expected value of the parameter in the request. |
Demonstrative Examples | The following code dynamically constructs and executes a SQL query that searches for
items matching a specified name. The query restricts the items displayed to those where
owner matches the user name of the currently-authenticated user. C# Example: ... string userName = ctx.getAuthenticatedUserName(); string query = "SELECT * FROM items WHERE owner = '" + userName + "' AND itemname = '" + ItemName.Text + "'"; sda = new SqlDataAdapter(query, conn); DataTable dt = new DataTable(); sda.Fill(dt); ... The query that this code intends to execute follows: SELECT * FROM items WHERE owner
= <userName> AND itemname = <itemName>; However, because the
query is constructed dynamically by concatenating a constant base query string and a user
input string, the query only behaves correctly if itemName does not contain a single-quote
character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for
itemName, then the query becomes the following: SELECT * FROM items WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a'; The addition of the OR 'a'='a' condition causes the
where clause to always evaluate to true, so the query becomes logically equivalent to the
much simpler query: SELECT * FROM items; This simplification of the query allows the
attacker to bypass the requirement that the query only return items owned by the
authenticated user; the query now returns all entries stored in the items table,
regardless of their specified owner.
This example examines the effects of a different malicious value passed to the query
constructed and executed in the above example. If an attacker with the user name hacker
enters the string "hacker'); DELETE FROM items; --" for itemName, then the query becomes
the following two queries: SQL Example: SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name'; DELETE FROM items; --' Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL
statements separated by semicolons to be executed at once. While this attack string
results in an error on Oracle and other database servers that do not allow the
batch-execution of statements separated by semicolons, on databases that do allow batch
execution, this type of attack allows the attacker to execute arbitrary commands against
the database. Notice the trailing pair of hyphens (--), which specifies to most database
servers that the remainder of the statement is to be treated as a comment and not executed
[19]. In this case the comment character serves to remove the trailing single-quote left
over from the modified query. On a database where comments are not allowed to be used in
this way, the general attack could still be made effective using a trick similar to the
one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items;
SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name'; DELETE FROM items; SELECT
* FROM items WHERE 'a'='a'; One traditional approach to preventing SQL injection attacks
is to handle them as an input validation problem and either accept only characters from a
whitelist of safe values or identify and escape a blacklist of potentially malicious
values. Whitelisting can be a very effective means of enforcing strict input validation
rules, but parameterized SQL statements require less maintenance and can offer more
guarantees with respect to security. As is almost always the case, blacklisting is riddled
with loopholes that make it ineffective at preventing SQL injection attacks. For example,
attackers can: - Target fields that are not quoted - Find ways to bypass the need for
certain escaped meta-characters - Use stored procedures to hide the injected
meta-characters Manually escaping characters in input to SQL queries can help, but it will
not make your application secure from SQL injection attacks. Another solution commonly
proposed for dealing with SQL injection attacks is to use stored procedures. Although
stored procedures prevent some types of SQL injection attacks, they fail to protect
against many others. For example, the following PL/SQL procedure is vulnerable to the same
SQL injection attack shown in the first example. procedure get_item ( itm_cv IN OUT
ItmCurTyp, usr in varchar2, itm in varchar2) is open itm_cv for ' SELECT * FROM items
WHERE ' || 'owner = '|| usr || ' AND itemname = ' || itm || '; end get_item; Stored
procedures typically help prevent SQL injection attacks by limiting the types of
statements that can be passed to their parameters. However, there are many ways around the
limitations and many interesting statements that can still be passed to stored procedures.
Again, stored procedures can prevent some exploits, but they will not make your
application secure against SQL injection attacks.
MS SQL has a built in function that enables shell command execution. An
SQL injection in such a context could be disastrous. For example, a query of the
form: SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='$user_input' ORDER BY PRICE Where $user_input is taken from the user and
unfiltered. If the user provides the string: ' exec master..xp_cmdshell 'vol' -- The query will take the following form: " SELECT ITEM,PRICE FROM PRODUCT WHERE ITEM_CATEGORY='' exec master..xp_cmdshell 'vol' --' ORDER BY PRICE Now, this query can be broken down into: [1] a first SQL query: SELECT ITEM,PRICE
FROM PRODUCT WHERE ITEM_CATEGORY='' [2] a second SQL query, which executes a shell
command: exec master..xp_cmdshell 'vol' [3] an MS SQL comment: --' ORDER BY PRICE As can
be seen, the malicious input changes the semantics of the query into a query, a shell
command execution and a comment. |
| Context Notes | SQL injection has become a common issue with database-driven web sites. The flaw is
easily detected, and easily exploited, and as such, any site or software package with even a
minimal user base is likely to be subject to an attempted attack of this kind. Essentially, the
attack is accomplished by placing a meta character into data input to then place SQL commands in
the control plane, which did not exist there before. This flaw depends on the fact that SQL makes
no real distinction between the control and data planes. If successful, SQL Injection attacks can give an attacker access to backend database
contents, the ability to remotely execute system commands, or in some circumstances the means to
take control of the Windows server hosting the database. Dynamically generating queries that include user input can lead to SQL injection
attacks. An attacker can insert SQL commands or modifiers in the user input that can cause the
query to behave in an unsafe manner. Constructing a dynamic SQL statement with user input may allow an attacker to modify
the statement's meaning or to execute arbitrary SQL commands. Factors: resultant to special character mismanagement, MAID, or blacklist/whitelist
problems. Can be primary to authentication errors. |