
Weakness ID: 89 (Weakness Base)Status: Draft
+ Description

Description Summary


Extended Description



+ Time of Introduction
  • Architecture and Design
  • Implementation
  • Operation
+ Applicable Platforms



Technology Classes


+ Modes of Introduction

This weakness typically appears in data-rich applications that save user inputs in a database.

+ Common Consequences

Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL injection vulnerabilities.







+ Likelihood of Exploit

Very High

+ Enabling Factors for Exploitation

The application dynamically generates queries that contain user input.

+ Detection Methods

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.

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.

+ Demonstrative Examples

Example 1

In 2008, a large number of web servers were compromised using the same SQL injection attack string. This single string worked against many different programs. The SQL injection was then used to modify the web sites to serve malicious code. [1]

Example 2


(Bad Code)
Example Language: C# 
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();

The query that this code intends to execute follows:

SELECT * FROM items WHERE owner = <userName> AND itemname = <itemName>;


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;


Example 3

This example examines the effects of a different malicious value passed to the query constructed and executed in the previous example.

If an attacker with the user name wiley enters the string:

name'; DELETE FROM items; --

for itemName, then the query becomes the following two queries:

Example Language: SQL 
SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name';

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. 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 the previous example.

If an attacker enters the string

name'; DELETE FROM items; SELECT * FROM items WHERE 'a'='a

Then the following three valid statements will be created:


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.



(Bad Code)
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;


Example 4

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:

(Bad Code)

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: "


Now, this query can be broken down into:


  • [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.

Example 5

This code intends to print a message summary given the message ID.

(Bad Code)
Example Language: PHP 
$id = $_COOKIE["mid"];
mysql_query("SELECT MessageID, Subject FROM messages WHERE MessageID = '$id'");

The programmer may have skipped any input validation on $id under the assumption that attackers cannot modify the cookie. However, this is easy to do with custom client code or even in the web browser.

While $id is wrapped in single quotes in the call to mysql_query(), an attacker could simply change the incoming mid cookie to:

1432' or '1' = '1

This would produce the resulting query:

SELECT MessageID, Subject FROM messages WHERE MessageID = '1432' or '1' = '1'

Not only will this retrieve message number 1432, it will retrieve all other messages.

In this case, the programmer could apply a simple modification to the code to eliminate the SQL injection:

(Good Code)
Example Language: PHP 
$id = intval($_COOKIE["mid"]);

However, if this code is intended to support multiple users with different message boxes, the code might also need an access control check (CWE-285) to ensure that the application user has the permission to see that message.

Example 6

This example attempts to take a last name provided by a user and enter it into a database.

(Bad Code)
Example Language: Perl 
$userKey = getUserID();
$name = getUserInput();
# ensure only letters, hyphens and apostrophe are allowed
$name = whiteList($name, "^a-zA-z'-$");
$query = "INSERT INTO last_names VALUES('$userKey', '$name')";

While the programmer applies a whitelist to the user input, it has shortcomings. First of all, the user is still allowed to provide hyphens which are used as comment structures in SQL. If a user specifies -- then the remainder of the statement will be treated as a comment, which may bypass security logic. Furthermore, the whitelist permits the apostrophe which is also a data / command separator in SQL. If a user supplies a name with an apostrophe, they may be able to alter the structure of the whole statement and even change control flow of the program, possibly accessing or modifying confidential information. In this situation, both the hyphen and apostrophe are legitimate characters for a last name and permitting them is required. Instead, a programmer may want to use a prepared statement or apply an encoding routine to the input to prevent any data / directive misinterpretations.

+ Observed Examples
CVE-2004-0366chain: SQL injection in library intended for database authentication allows SQL injection and authentication bypass.
CVE-2008-2790SQL injection through an ID that was supposed to be numeric.
CVE-2008-2223SQL injection through an ID that was supposed to be numeric.
CVE-2007-6602SQL injection via user name.
CVE-2008-5817SQL injection via user name or password fields.
CVE-2003-0377SQL injection in security product, using a crafted group name.
CVE-2008-2380SQL injection in authentication library.
+ Potential Mitigations

Phases: Architecture and Design; Requirements

Use languages, libraries, or frameworks that make it easier to generate properly encoded output.


Phase: Architecture and Design

Strategy: Parameterization


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 you may re-introduce the possibility of SQL injection.

Phase: Architecture and Design


Phase: Architecture and Design


Phase: Implementation

If you need to use dynamically-generated query strings in spite of the risk, use proper encoding and escaping of inputs. Instead of building your own 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 SQL injection. For MySQL, the mysql_real_escape_string() API function is available in both C and PHP.

Phase: Implementation

Strategy: Input Validation



When constructing SQL query strings, use stringent whitelists that limit the character set based on the expected value of the parameter in the request. This will indirectly limit the scope of an attack, but this technique is less important than proper output encoding and escaping.

Note that proper output encoding, escaping, and quoting is the most effective solution for preventing SQL injection, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent SQL injection, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, the name "O'Reilly" would likely pass the validation step, since it is a common last name in the English language. However, it cannot be directly inserted into the database because it contains the "'" apostrophe character, which would need to be escaped or otherwise handled. In this case, stripping the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded.


Phases: Testing; Implementation

Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.

Phase: Testing


Phase: Operation

Use an application firewall that can detect attacks against this weakness. This might not catch all attacks, and it might require some effort for customization. However, it can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class20Improper Input Validation
Seven Pernicious Kingdoms (primary)700
ChildOfWeakness ClassWeakness Class77Improper Sanitization of Special Elements used in a Command ('Command Injection')
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory713OWASP Top Ten 2007 Category A2 - Injection Flaws
Weaknesses in OWASP Top Ten (2007) (primary)629
ChildOfCategoryCategory722OWASP Top Ten 2004 Category A1 - Unvalidated Input
Weaknesses in OWASP Top Ten (2004)711
ChildOfCategoryCategory727OWASP Top Ten 2004 Category A6 - Injection Flaws
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory7512009 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfCategoryCategory8012010 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ParentOfWeakness VariantWeakness Variant564SQL Injection: Hibernate
Development Concepts (primary)699
Research Concepts (primary)1000
MemberOfViewView630Weaknesses Examined by SAMATE
Weaknesses Examined by SAMATE (primary)630
MemberOfViewView635Weaknesses Used by NVD
Weaknesses Used by NVD (primary)635
CanFollowWeakness BaseWeakness Base456Missing Initialization
Research Concepts1000
+ Relationship Notes

SQL injection can be resultant from special character mismanagement, MAID, or blacklist/whitelist problems. It can be primary to authentication errors.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERSQL injection
7 Pernicious KingdomsSQL Injection
CLASPSQL injection
OWASP Top Ten 2007A2CWE More SpecificInjection Flaws
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
OWASP Top Ten 2004A6CWE More SpecificInjection Flaws
WASC19SQL Injection
+ Related Attack Patterns
CAPEC-IDAttack Pattern Name
(CAPEC Version: 1.4)
7Blind SQL Injection
66SQL Injection
108Command Line Execution through SQL Injection
109Object Relational Mapping Injection
110SQL Injection through SOAP Parameter Tampering
+ White Box Definitions

A weakness where the code path has:

1. start statement that accepts input and

2. end statement that performs an SQL command where

a. the input is part of the SQL command and

b. input contains SQL syntax (esp. query separator)

+ References
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 1: SQL Injection." Page 3. McGraw-Hill. 2010.
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 12, "Database Input Issues" Page 397. 2nd Edition. Microsoft. 2002.
OWASP. "SQL Injection Prevention Cheat Sheet". <>.
Steven Friedl. "SQL Injection Attacks by Example". 2007-10-10. <>.
Ferruh Mavituna. "SQL Injection Cheat Sheet". 2007-03-15. <>.
David Litchfield, Chris Anley, John Heasman and Bill Grindlay. "The Database Hacker's Handbook: Defending Database Servers". Wiley. 2005-07-14.
David Litchfield. "The Oracle Hacker's Handbook: Hacking and Defending Oracle". Wiley. 2007-01-30.
Microsoft. "SQL Injection". December 2008. <>.
Microsoft Security Vulnerability Research & Defense. "SQL Injection Attack". <>.
Michael Howard. "Giving SQL Injection the Respect it Deserves". 2008-05-15. <>.
+ Content History
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
7 Pernicious KingdomsExternally Mined
CLASPExternally Mined
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time of Introduction
2008-08-01KDM AnalyticsExternal
added/updated white box definitions
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Applicable Platforms, Common Consequences, Modes of Introduction, Name, Relationships, Other Notes, Relationship Notes, Taxonomy Mappings
2008-10-14CWE Content TeamMITREInternal
updated Description
2008-11-24CWE Content TeamMITREInternal
updated Observed Examples
2009-01-12CWE Content TeamMITREInternal
updated Demonstrative Examples, Description, Enabling Factors for Exploitation, Modes of Introduction, Name, Observed Examples, Other Notes, Potential Mitigations, References, Relationships
2009-03-10CWE Content TeamMITREInternal
updated Potential Mitigations
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative Examples, Name, Related Attack Patterns
2009-07-17KDM AnalyticsExternal
Improved the White Box Definition
2009-07-27CWE Content TeamMITREInternal
updated Description, Name, White Box Definitions
2009-12-28CWE Content TeamMITREInternal
updated Potential Mitigations
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11SQL Injection
2008-09-09Failure to Sanitize Data into SQL Queries (aka 'SQL Injection')
2009-01-12Failure to Sanitize Data within SQL Queries (aka 'SQL Injection')
2009-05-27Failure to Preserve SQL Query Structure (aka 'SQL Injection')
2009-07-27Failure to Preserve SQL Query Structure ('SQL Injection')