Blind SQL Injection results from an insufficient mitigation for SQL
Injection. Although suppressing database error messages are considered best
practice, the suppression alone is not sufficient to prevent SQL Injection.
Blind SQL Injection is a form of SQL Injection that overcomes the lack of
error messages. Without the error messages that facilitate SQL Injection,
the attacker constructs input strings that probe the target through simple
Boolean SQL expressions. The attacker can determine if the syntax and
structure of the injection was successful based on whether the query was
executed or not. Applied iteratively, the attacker determines how and where
the target is vulnerable to SQL Injection.
For example, an attacker may try entering something like "username' AND
1=1; --" in an input field. If the result is the same as when the attacker
entered "username" in the field, then the attacker knows that the
application is vulnerable to SQL Injection. The attacker can then ask yes/no
questions from the database server to extract information from it. For
example, the attacker can extract table names from a database using the
following types of queries:
"username' AND ascii(lower(substring((SELECT TOP 1 name FROM
sysobjects WHERE xtype='U'), 1, 1))) > 108".
If the above query executes properly, then the attacker knows that the
first character in a table name in the database is a letter between m
and z. If it doesn't, then the attacker knows that the character must be
between a and l (assuming of course that table names only contain
alphabetic characters). By performing a binary search on all character
positions, the attacker can determine all table names in the database.
Subsequently, the attacker may execute an actual attack and send
something like:
"username'; DROP TABLE trades; --
Attack Execution Flow
Explore
Hypothesize SQL queries in
application:
Generated hypotheses regarding the SQL queries in
an application. For example, the attacker may
hypothesize that his input is passed directly into a
query that looks like:
"SELECT * FROM orders WHERE ordernum =
_____"
or
"SELECT * FROM orders WHERE ordernum IN
(_____)"
or
"SELECT * FROM orders WHERE ordernum in
(_____) ORDER BY _____"
Of course, there are many other
possibilities.
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Research types of SQL queries and determine
which ones could be used at various places in an
application.
env-All
Determine how to inject information into
the queries:
Determine how to inject information into the
queries from the previous step such that the
injection does not impact their logic. For example,
the following are possible injections for those
queries:
"5' OR 1=1; --"
and
"5) OR 1=1; --"
and
"ordernum DESC; --"
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Add clauses to the SQL queries such that the
query logic does not change.
env-All
2
Add delays to the SQL queries in case server
does not provide clear error messages (e.g.
WAITFOR DELAY '0:0:10' in SQL Server or
BENCHMARK(1000000000,MD5(1) in MySQL). If these
can be injected into the queries, then the length
of time that the server takes to respond reveals
whether the query is injectable or not.
env-All
Outcomes
ID
type
Outcome Description
1
Success
At least one way to complete a
hypothesized SQL query that would violate the
application developer's
assumptions.
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 the values determined
in the previous step. If an error does not occur,
then the attacker knows that the SQL injection was
successful.
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
Unusual queries such
as the ones described in the previous step, in
application logs. Log files may contain unusual
messages such as "User bob' OR 1=1; -- logged in".
Operators should be alerted when such SQL commands
appear in the logs.
2
Preventative
Input validation of
user-controlled data before including it in a SQL
query
3
Preventative
Use APIs that help
mitigate SQL injection (such as PreparedStatement
in Java)
Determine database
type:
Determines the type of the database, such as MS
SQL Server or Oracle or MySQL, using logical
conditions as part of the injected queries
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Try injecting a string containing
char(0x31)=char(0x31) (this evaluates to 1=1 in
SQL Server only)
Inject other database-specific commands into
input fields susceptible to SQL Injection. The
attacker can determine the type of database that
is running by checking whether the query executed
successfully or not (i.e. wheter the attacker
received a normal response from the server or
not).
Desired information about
database schema extracted.
2
Failure
Desired information about
database schema could not be
extracted.
Security Controls
ID
type
Security Control Description
1
Detective
Large number of
unusual queries in database
logs.
Exploit SQL Injection
vulnerability:
Use the information obtained in the previous steps
to successfully inject the database in order to
bypass checks or modify, add, retrieve or delete
data from the database
Attack Step Techniques
ID
Attack Step Technique Description
Environments
1
Use information about how to inject commands
into SQL queries as well as information about the
database schema to execute attacks such as
dropping tables, inserting records, etc.
Attacker achieves goal of
unauthorized system access, denial of service,
etc.
2
Failure
Attacker cannot exploit the
information gathered by blind SQL
Injection
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: High
Methods of Attack
Injection
Analysis
Examples-Instances
Description
In the PHP application TimeSheet 1.1, an attacker can successfully
retrieve username and password hashes from the database using Blind SQL
Injection. If the attacker is aware of the local path structure, the
attacker can also remotely execute arbitrary code and write the output
of the injected queries to the local path. Blind SQL Injection is
possible since the application does not properly sanitize the
$_POST['username'] variable in the login.php file.
Related Vulnerabilities
CVE-2006-4705
Attacker Skills or Knowledge Required
Skill or Knowledge Level: Medium
Determining the database type and version, as well as the right number
and type of parameters to the query being injected in the absence of
error messages requires greater skill than reverse-engineering database
error messages.
Resources Required
None
Probing Techniques
In order to determine the right syntax for the query to inject, the
attacker tries to determine the right number of parameters to the query and
their types. This is achieved by formulating conditions that result in a
true/false answer from the database. If the logical condition is true, the
database will execute the rest of the query. If not, a custom error page or
a default page is returned. Another approach is to ask such true/false
questions of the database and note the response times to a query with a
logically true condition and one with a false condition.
Indicators-Warnings of Attack
The only indicators of successful Blind SQL Injection are the application
or database logs that show similar queries with slightly differing logical
conditions that increase in complexity over time. However, this requires
extensive logging as well as knowledge of the queries that can be used to
perform such injection and return meaningful information from the
database.
Solutions and Mitigations
Security by Obscurity is not a solution to preventing SQL Injection.
Rather than suppress error messages and exceptions, the application must
handle them gracefully, returning either a custom error page or redirecting
the user to a default page, without revealing any information about the
database or the application internals.
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.
Attack Motivation-Consequences
Data Modification
Information Leakage
Run Arbitrary Code
Injection Vector
User-controllable input to the application
Payload
SQL statements intended to bypass checks or retrieve information about the
database
Activation Zone
Back-end database
Payload Activation Impact
The injected SQL statements are such that they result in a true/false query to
the database. If the database evaluates a statement to be logically true, it
responds with the requested data. If the condition is evaluated to be logically
false, an error is returned. The attacker modifies the boolean condition each
time to gain information from the database.
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.
Special characters in user-controllable input must be escaped before use
by the application.
Employ application-level safeguards to filter data and handle exceptions
gracefully.
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
CIA Impact
Confidentiality Impact: High
Integrity Impact: High
Availability Impact: High
Technical Context
Architectural Paradigms
All
Frameworks
All
Platforms
All
Languages
All
References
CWE - Input Validation
CWE - Improper Error Handling
Content History
Submissions
Submitter
Date
Comments
Chiradeep B Chhaya
2007-02-22
Third Draft - Revised to schema
v1.4
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,
Attack Prerequisites and Related Attack Patterns
Sean Barnum
Cigital, Inc
2007-04-13
Modified pattern content according to review and
feedback
Vision and Technical Leadership provided by Cigital, Inc.
This Web site is hosted by The MITRE Corporation.
Copyright 2009, The MITRE Corporation. CAPEC and the CAPEC logo are trademarks of The MITRE Corporation.
Description
