This attack exploits target software that constructs SQL statements based
on user input. An attacker crafts input strings so that when the target
software constructs SQL statements based on the input, the resulting SQL
statement performs actions other than those the application intended.
SQL Injection results from failure of the application to appropriately
validate input. When specially crafted user-controlled input consisting of
SQL syntax is used without proper validation as part of SQL queries, it is
possible to glean information from the database in ways not envisaged during
application design. Depending upon the database and the design of the
application, it may also be possible to leverage injection to have the
database execute system-related commands of the attacker's choice. SQL
Injection enables an attacker to talk directly to the database, thus
bypassing the application completely. Sucessful injection can cause
information disclosure as well as ability to add or modify data in the
database. In order to successfully inject SQL and retrieve information from
a database, an attacker:
Attack Execution Flow
Explore
Survey application:
The attacker first takes an inventory of the
functionality exposed by the application.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Spider web sites for all available
links
env-Web
2
Sniff network communications with
application using a utility such as
WireShark.
env-ClientServer env-Peer2Peer
env-CommProtocol
Outcomes
ID
Type
Outcome Description
1
Success
At least one data input to
application identified.
2
Failure
No inputs to application
identified. Note that just because no inputs are
identified does not mean that the application will
not accept any.
Experiment
Determine user-controllable input
susceptible to injection:
Determine the user-controllable input susceptible
to injection. For each user-controllable input that
the attacker suspects is vulnerable to SQL
injection, attempt to inject characters that have
special meaning in SQL (such as a single quote
character, a double quote character, two hyphens, a
paranthesis, etc.). The goal is to create a SQL
query with an invalid syntax.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Use web browser to inject input through text
fields or through HTTP GET parameters.
env-Web
2
Use a web application debugging tool such as
Tamper Data, TamperIE, WebScarab,etc. to modify
HTTP POST parameters, hidden fields, non-freeform
fields, etc.
env-Web
3
Use network-level packet injection tools
such as netcat to inject input
At least one user-controllable
input susceptible to injection
found.
2
Failure
No user-controllable input
susceptible to injection
found.
Security Controls
ID
Type
Security Control Description
1
Detective
Search for and alert
on unexpected SQL keywords in application logs
(e.g. SELECT, DROP,
etc.).
2
Preventative
Input validation of
user-controlled data before including it in a SQL
query
3
Preventative
Use parameterized
queries (e.g. PreparedStatement in Java, and
Command.Parameters.Add() to set query parameters
in .NET)
Experiment and try to exploit SQL
Injection vulnerability:
After determining that a given input is vulnerable
to SQL Injection, hypothesize what the underlying
query looks like. Iteratively try to add logic to
the query to extract information from the database,
or to modify or delete information in the
database.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Use public resources such as "SQL Injection
Cheat Sheet" at
http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/,
and try different approaches for adding logic to
SQL queries.
Add logic to query, and use detailed error
messages from the server to debug the query. For
example, if adding a single quote to a query
causes an error message, try : "' OR 1=1; --", or
something else that would syntactically complete a
hypothesized query. Iteratively refine the
query.
If a denial of service attack is the goal,
try stacking queries. This does not work on all
platforms (most notably, it does not work on
Oracle or MySQL). Examples of inputs to try
include: "'; DROP TABLE SYSOBJECTS; --" and "');
DROP TABLE SYSOBJECTS; --". These particular
queries will likely not work because the
SYSOBJECTS table is generally protected.
Attacker achieves goal of
unauthorized system access, denial of service,
etc.
2
Failure
Attacker unable to exploit SQL
Injection vulnerability.
Attack Prerequisites
SQL queries used by the application to store, retrieve or modify
data.
User-controllable input that is not properly validated by the application
as part of SQL queries.
Typical Likelihood of Exploit
Likelihood: Very High
Methods of Attack
Injection
Examples-Instances
Description
With PHP-Nuke versions 7.9 and earlier, an attacker can successfully
access and modify data, including sensitive contents such as usernames
and password hashes, and compromise the application through SQL
Injection. The protection mechanism against SQL Injection employs a
blacklist approach to input validation. However, because of improper
blacklisting, it is possible to inject content such as "foo'/**/UNION"
or "foo UNION/**/" to bypass validation and glean sensitive information
from the database.
Related Vulnerabilities
CVE-2006-5525
Attacker Skills or Knowledge Required
Skill or Knowledge Level: Low
It is fairly simple for someone with basic SQL knowledge to perform
SQL injection, in general. In certain instances, however, specific
knowledge of the database employed may be required.
Resources Required
None
Probing Techniques
Description
The attacker tries to inject characters that can cause a SQL error,
such as single-quote (') or keywords such as "UNION" and "OR". If the
injection of such characters into the input causes a SQL error and the
resulting error is displayed unfiltered, the attacker can begin to
determine the nature of input validation and structure of SQL queries. A
typical error resulting from such injection would look like:
"You have an error in your SQL Syntax. Check your manual for the
right syntax to use near
') FROM db_users.user_table"
Description
With available design documentation and code, the attacker can
determine whether all user-controllable inputs are being validated or
not, and also the structure of SQL queries that such inputs feed
into.
Indicators-Warnings of Attack
Description
Too many false or invalid queries to the database, especially those
caused by malformed input.
Solutions and Mitigations
Strong input validation - All user-controllable input must be validated
and filtered for illegal characters as well as SQL content. Keywords such as
UNION, SELECT or INSERT must be filtered in addition to characters such as a
single-quote(') or SQL-comments (--) based on the context in which they
appear.
Use of parameterized queries or stored procedures - Parameterization
causes the input to be restricted to certain domains, such as strings or
integers, and any input outside such domains is considered invalid and the
query fails. Note that SQL Injection is possible even in the presence of
stored procedures if the eventual query is constructed dynamically.
Use of custom error pages - Attackers can glean information about the
nature of queries from descriptive error messages. Input validation must be
coupled with customized error pages that inform about an error without
disclosing information about the database or application.
Attack Motivation-Consequences
Scope
Technical Impact
Note
Integrity
Modify application
data
Confidentiality
Read application
data
Confidentiality
Integrity
Availability
Execute unauthorized code or
commands
Confidentiality
Access_Control
Authorization
Gain privileges / assume
identity
Injection Vector
User-controllable input used as part of non-parameterized SQL queries: This
may include input fields on web forms, data in user-accessible files or even
command-line parameters.
Payload
SQL statements intended to reveal information or run malicious code
Activation Zone
Back-end database
Payload Activation Impact
Description
When malicious SQL content is executed by the database, it can lead to
arbitrary queries being executed, causing disclosure of information,
unauthorized access, privilege escalation and possibly system
compromise.
Special characters in user-controllable input must be escaped before use
by the application.
Only use parameterized stored procedures to query the database.
Input data must be revalidated in the parameterized stored
procedures.
Custom error pages must be used to handle exceptions such that they do not
reveal any information about the architecture of the application or the
database.
Related Security Principles
Reluctance to Trust
Failing Securely
Defense in Depth
Related Guidelines
Never Use Input as Part of a Directive to any Internal Component
Handle All Errors Safely
Purposes
Penetration
Exploitation
CIA Impact
Confidentiality Impact: High
Integrity Impact: High
Availability Impact: High
Technical Context
Architectural Paradigms
All
Frameworks
All
Platforms
All
Languages
All
References
CWE - SQL Injection
CWE - Input Validation
CWE - Improper Error Handling
Content History
Submissions
Submitter
Date
Comments
Chiradeep B Chhaya
2007-01-12
Second Draft
Modifications
Modifier
Organization
Date
Comments
Malik Hamro
Cigital, Inc
2007-02-27
Reformat to new schema and
review
Sean Barnum
Cigital, Inc
2007-03-05
Review and revise
Richard Struse
VOXEM, Inc
2007-03-26
Review and feedback leading to changes in Description
and Related Attack Patterns
Sean Barnum
Cigital, Inc
2007-04-13
Modified pattern content according to review and
feedback
Description
