CAPEC-7 - Blind SQL Injection

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' AND ascii(lower(substring((SELECT TOP 1 name FROM sysobjects WHERE xtype='U'), 1, 1))) > 108".

Severity

Likelihood

Confidentiality

Integrity

Availability

  • Attack Methods 2
  • Injection
  • Analysis
  • Purposes 1
  • Penetration
  • Sec Principles 3
  • Reluctance to Trust
  • Failing Securely
  • Defense in Depth
  • Scopes 3
  • Modify application data
  • Integrity
  • Read application data
  • Confidentiality
  • Execute unauthorized code or commands
  • Availability
  • Integrity
  • Confidentiality

Medium level: 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.

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.

None

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.

Never Use Input as Part of a Directive to any Internal Component

Handle All Errors Safely

Step 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:.

Tecnique ID: 1 - Environment(s) env-All

Research types of SQL queries and determine which ones could be used at various places in an application.

Step 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:.

Tecnique ID: 1 - Environment(s) env-All

Add clauses to the SQL queries such that the query logic does not change.

Tecnique ID: 2 - Environment(s) 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.

Outcome ID: 1

Type: Success

At least one way to complete a hypothesized SQL query that would violate the application developer's assumptions.



Step 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..

Tecnique ID: 1 - Environment(s) env-Web

Use web browser to inject input through text fields or through HTTP GET parameters.

Tecnique ID: 2 - Environment(s) 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.

Tecnique ID: 3 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Use network-level packet injection tools such as netcat to inject input

Tecnique ID: 4 - Environment(s) env-ClientServer env-Peer2Peer env-CommProtocol

Use modified client (modified by reverse engineering) to inject input.

Indicator ID: 1 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Type: Positive

Attacker receives normal response from server.

Indicator ID: 2 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Type: Positive

Response takes expected amount of time after delay is injected.

Indicator ID: 3 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Type: Negative

Server sends a specific error message that indicates programmatic parsing of the input data (e.g. NumberFormatException)


Security Control ID: 1

Type: 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.

Security Control ID: 2

Type: Preventative

Input validation of user-controlled data before including it in a SQL query

Security Control ID: 3

Type: Preventative

Use APIs that help mitigate SQL injection (such as PreparedStatement in Java)


Outcome ID: 1

Type: Success

At least one user-controllable input susceptible to injection found.

Outcome ID: 2

Type: Failure

No user-controllable input susceptible to injection found.


Step 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.

Tecnique ID: 1 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Try injecting a string containing char(0x31)=char(0x31) (this evaluates to 1=1 in SQL Server only)

Tecnique ID: 2 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Try injecting a string containing 0x313D31 (this evaluates to 1=1 in MySQL only)

Tecnique ID: 3 - Environment(s) 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. whether the attacker received a normal response from the server or not).

Indicator ID: 1 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Type: Positive

Success outcome in previous step

Indicator ID: 2 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Type: Negative

Failure outcome in previous step


Outcome ID: 1

Type: Success

Database platform in use discovered.

Outcome ID: 2

Type: Failure

Database platform in use not discovered.



Step 1 - Extract information about database schema

Extract information about database schema by getting the database to answer yes/no questions about the schema..

Tecnique ID: 1 - Environment(s) env-Web

Automatically extract database schema using a tool such as Absinthe.

Tecnique ID: 2 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Manually perform the blind SQL Injection to extract desired information about the database schema.

Indicator ID: 1 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Type: Positive

Success outcome in previous step.

Indicator ID: 2 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Type: Negative

Failure outcome in previous step.


Security Control ID: 1

Type: Detective

Large number of unusual queries in database logs.


Outcome ID: 1

Type: Success

Desired information about database schema extracted.

Outcome ID: 2

Type: Failure

Desired information about database schema could not be extracted.


Step 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.

Tecnique ID: 1 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

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.

Indicator ID: 1 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Type: Positive

Success outcome in previous step.

Indicator ID: 2 - Environment(s) env-Web env-ClientServer env-Peer2Peer env-CommProtocol

Type: Negative

Failure outcome in previous step.


Outcome ID: 1

Type: Success

Attacker achieves goal of unauthorized system access, denial of service, etc.

Outcome ID: 2

Type: Failure

Attacker cannot exploit the information gathered by blind SQL Injection



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.

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.