CAPEC

Common Attack Pattern Enumeration and Classification
Common Attack Pattern Enumeration and Classification

A Community Knowledge Resource for Building Secure Software

Home > CAPEC List > Individual CAPEC Dictionary Definition (Release 1.1)   View the CAPEC List

Individual CAPEC Dictionary Definition (Release 1.1)
Individual CAPEC Dictionary Definition (Release 1.1)

Blind SQL Injection
Attack Pattern ID
Pattern Abstraction: Detailed

7

Typical Severity

High

Description

Summary

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.
        In order to achieve this using Blind SQL Injection, an attacker:
      
      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
  1. 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 Technique
    DescriptionEnvironments
    Research types of SQL queries and determine which ones could be used at various places in an application.env-All
  2. 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
    DescriptionEnvironments
    Add clauses to the SQL queries such that the query logic does not change.env-All
    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
    Outcome
    IDTypeDescription
    c7s2o1SuccessAt least one way to complete a hypothesized SQL query that would violate the application developer's assumptions.
Experiment
  1. 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
    DescriptionEnvironments
    Use web browser to inject input through text fields or through HTTP GET parameters.env-Web
    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
    Use network-level packet injection tools such as netcat to inject inputenv-Web env-ClientServer env-Peer2Peer env-CommProtocol
    Use modified client (modified by reverse engineering) to inject input.env-ClientServer env-Peer2Peer env-CommProtocol
    Indicators of Susceptibility
    IDTypeDescriptionEnvironments
    c7s3i1PositiveAttacker receives normal response from server.env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    c7s3i2PositiveResponse takes expected amount of time after delay is injected.env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    c7s3i3NegativeServer sends a specific error message that indicates programmatic parsing of the input data (e.g. NumberFormatException)env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    Outcomes
    IDTypeDescription
    c7s3o1SuccessAt least one user-controllable input susceptible to injection found.
    c7s3o2FailureNo user-controllable input susceptible to injection found.
    Security Controls
    IDTypeDescription
    c7s3sc1DetectiveUnusual 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.
    c7s3sc2PreventativeInput validation of user-controlled data before including it in a SQL query
    c7s3sc3PreventativeUse APIs that help mitigate SQL injection (such as PreparedStatement in Java)
  2. 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
    DescriptionEnvironments
    Try injecting a string containing char(0x31)=char(0x31) (this evaluates to 1=1 in SQL Server only)env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    Try injecting a string containing 0x313D31 (this evaluates to 1=1 in MySQL only)env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    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).env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    Indicators of Susceptibility
    IDTypeDescriptionEnvironments
    c7s4i1PositiveSuccess outcome in previous stepenv-Web env-ClientServer env-Peer2Peer env-CommProtocol
    c7s4i2NegativeFailure outcome in previous stepenv-Web env-ClientServer env-Peer2Peer env-CommProtocol
    Outcomes
    IDTypeDescription
    c7s4o1SuccessDatabase platform in use discovered.
    c7s4o2FailureDatabase platform in use not discovered.
Exploit
  1. Extract information about database schema: Extract information about database schema by getting the database to answer yes/no questions about the schema.

    Attack Step Techniques
    DescriptionEnvironments
    Automatically extract database schema using a tool such as Absinthe.env-Web
    Manually perform the blind SQL Injection to extract desired information about the database schema.env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    Indicators of Susceptibility
    IDTypeDescriptionEnvironments
    c7s5i1PositiveSuccess outcome in previous step.env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    c7s5i2NegativeFailure outcome in previous step.env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    Outcomes
    IDTypeDescription
    c7s5o1SuccessDesired information about database schema extracted.
    c7s5o2FailureDesired information about database schema could not be extracted.
    Security Control
    IDTypeDescription
    c7s5sc1DetectiveLarge number of unusual queries in database logs.
  2. 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 Technique
    DescriptionEnvironments
    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.env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    Indicators of Susceptibility
    IDTypeDescriptionEnvironments
    c7s6i1PositiveSuccess outcome in previous step.env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    c7s6i2NegativeFailure outcome in previous step.env-Web env-ClientServer env-Peer2Peer env-CommProtocol
    Outcomes
    IDTypeDescription
    c7s6o1SuccessAttacker achieves goal of unauthorized system access, denial of service, etc.
    c7s6o2FailureAttacker 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

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 Vulnerability

CVE-2006-4705

Attacker Skill or Knowledge Required

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
Context Description

An attacker attempts Blind SQL Injection when traditional SQL Injection is not possible due to suppression of error messages.
      
      Blind SQL Injection is performed by appending logical conditions to the query being injected such that they evaluate to true or false in the context of the data stored in the database. The first step is to get the syntax for the injected query right. For example, consider a database that has a table named "users". Consider the following query:
      SELECT fname, lname, dob, ssn, address FROM users WHERE userid="user1" AND password="user1pwd";
      
      To determine whether the "userid" field is injectable or not, the attacker tries an input such as
      user1" AND 3>1+1;--
      
      This causes the following query
      SELECT fname, lname, dob, ssn, address FROM users WHERE userid="user1" AND 3>1+1;--
      
      to be passed to the database. If the parameter is injectable, the database evaluates 3>1+1 to be true and executes the query. If, on the other hand, a condition such as 3<2 were passed, the database would return an error. Since the application suppresses such errors, the attacker never sees it. However, the application may simply hang or it may redirect to a custom error page or a default page, which is definitely an indication that the injected condition was evaluated to be false. The query can also fail if the original condition was within parentheses, such as
      
      WHERE (userid="johns" AND password="abracadabra")
      
      In such a case, the attacker will have to try injection such that the parentheses match up.
      
      Once the attacker gets the syntax right, the next step is to identify the database. This can be achieved by using operators that are unique to each database engine. For example, a condition such as "abc" = "a"+"bc" evaluates to true on MS SQL Server whereas it evaluates to false on Oracle since the concatentation operator is ||. Another approach is using system-specific functions such as those for date and time.
      
      The next step is to determine the number and type of parameters. This can again be achieved by exploiting the SELECT...WHERE conditions or using UNION SELECT statements with dummy numeric or character-based parameters.
      
      Once the type of database as well as the structure of the query has been mapped out by asking a number of questions to the database, the attacker is in a position to inject the database and extract information from it.
      
      Blind SQL Injection is a classic example of solution by reduction where the domain to be attacked is successively narrowed down by the attacker through true or false queries to the database.
    

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.

Related Weaknesses
CWE-IDWeakness NameWeakness Relationship Type
89Failure to Sanitize Data into SQL Queries (aka 'SQL Injection')Targeted
209Error Message Information LeaksTargeted
74Failure to Sanitize Data into a Different Plane (aka 'Injection')Secondary
20Insufficient Input ValidationSecondary
390Detection of Error Condition Without ActionSecondary
Related Attack Patterns
IDNameRelationship TypeRelationship Description
66SQL InjectionOccasionally Precedes
Relevant Security Requirements

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
Purpose

Penetration

CIA Impact
Confidentiality ImpactIntegrity ImpactAvailability Impact
HighHighHigh
Technical Context
Architectural ParadigmFrameworkPlatformLanguage
AllAllAllAll
References

CWE - Input Validation

CWE - Improper Error Handling

Source
Submission(s)
SubmitterOrganizationDateComment
Chiradeep B Chhaya2007-02-22Third Draft - Revised to schema v1.4
Modification(s)
ModifierOrganizationDateComment
Malik HamroCigital, Inc2007-02-27Reformat to new schema and review
Sean BarnumCigital, Inc2007-03-05Review and revise
Richard StruseVOXEM, Inc2007-03-26Review and feedback leading to changes in Description, Attack Prerequisites and Related Attack Patterns
Sean BarnumCigital, Inc2007-04-13Modified pattern content according to review and feedback
Amit SethiCigital, Inc.2007-10-29Added extended Attack Execution Flow
 
Page Last Updated: April 18, 2008