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 adversary constructs input strings that probe the target through simple Boolean SQL expressions. The adversary can determine if the syntax and structure of the injection was successful based on whether the query was executed or not. Applied iteratively, the adversary determines how and where the target is vulnerable to SQL Injection.

1. [Explore] [Hypothesize SQL queries in application] Generated hypotheses regarding the SQL queries in an application. For example, the adversary may hypothesize that their 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. 2. [Explore] [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; --" 3. [Experiment] [Determine user-controllable input susceptible to injection] Determine the user-controllable input susceptible to injection. For each user-controllable input that the adversary suspects is vulnerable to SQL injection, attempt to inject the values determined in the previous step. If an error does not occur, then the adversary knows that the SQL injection was successful. 4. [Experiment] [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 5. [Exploit] [Extract information about database schema] Extract information about database schema by getting the database to answer yes/no questions about the schema. 6. [Exploit] [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

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

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

• Integrity: Modify Data • Confidentiality: Read Data • Confidentiality, Integrity, Availability: Execute Unauthorized Commands

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