Boolean-Based Blind SQL Injection

Hello! Welcome to the next lesson in our SQL injection module.

In our previous session, we mastered union-based SQL injection, a powerful technique for exfiltrating data when the application displays query results on the page. We learned how to find the column count, identify usable columns, and merge our own malicious query to dump database contents.

However, many modern applications are configured to be more secure. They don't display database errors, nor do they reflect query data directly on the page. When you inject a payload, the page might look exactly the same, or it might just show a generic "not found" message. This is where we enter the world of blind SQL injection.

Today, we will focus on the first type of blind SQLi: boolean-based blind SQL injection. Instead of receiving data directly, we will learn to act like a detective, asking the database a series of "true or false" questions and inferring the answers from subtle changes in the application's response. This method is slow and methodical, but it is a fundamental skill for any bug bounty hunter or penetration tester.

By the end of this lesson, you will be able to extract data from a database using boolean-based blind SQL injection techniques.

1. The "Blind" Condition: Seeing Without Seeing

The core principle of boolean-based blind SQL injection is to find a condition that makes the application behave differently for a "true" response versus a "false" one. We don't get the data back, but we get a binary signal (a "yes" or "no") that tells us if our injected query was successful.

What does this different behavior look like?

• A message might appear or disappear (e.g., "Welcome back!" is present for a true condition but absent for a false one).
• The HTTP response status code might change (e.g., 200 OK for true, 404 Not Found for false).
• The response page might have a different size.

Our first step is always to probe an input parameter to see if we can trigger such a binary response.

To see a practical demonstration of identifying a blind SQLi vulnerability, let's watch how an attacker analyzes an application's cookie to find a reliable true/false indicator.

This different response based on a boolean condition is the foothold we need.

2. Manual Extraction: The Slow Road to Data

Once you have a confirmed true/false indicator, you can start asking the database questions to exfiltrate data one character at a time. This is a tedious process, but understanding it is crucial before moving to automation.

The primary tool for this is the SUBSTRING() function (or SUBSTR() in some databases), which lets you select a portion of a string. We can use it to ask questions like, "Is the first character of the administrator's password 'a'?"

Here is an example payload structure:
' AND (SELECT SUBSTRING(password, 1, 1) FROM users WHERE username = 'administrator') = 'a'--

Let's break this down:

• SUBSTRING(password, 1, 1): From the password column, start at position 1 and select 1 character.
• ... = 'a': Compare that character to 'a'.

If the page returns the "true" response, you know the first character is 'a'. If not, you try 'b', then 'c', and so on, until you get a "true" response. Then you move to the second character (SUBSTRING(password, 2, 1)) and repeat the process.

The following resource provides a clear textual explanation of using the SUBSTRING function for this purpose.

Test your understanding!

You are attacking a website where a "true" condition makes the page title "Welcome!" and a "false" condition makes it "Access Denied." You want to find the first character of the database version. You inject the payload ' AND SUBSTRING(@@version, 1, 1) = '5'--. The page title is "Welcome!".

What can you conclude?

Show answer

You can conclude that the first character of the database version string is '5'. The "Welcome!" title is your "true" indicator, and your injected query SUBSTRING(@@version, 1, 1) = '5' evaluated to true.

3. Automation: The Professional Approach

As you've realized, manually extracting data character-by-character is impractical for anything longer than a few characters. In professional settings, this process is always automated. We'll explore two primary methods: custom scripting and using Burp Suite Intruder.

Method 1: Custom Scripting with Python

Given your background in computer science and comfort with Python, scripting is a powerful and flexible approach. A script can automate the tedious process of iterating through character positions and testing all possible characters for each position.

This is a great chance to apply your programming skills to a real-world security task. Watch the following clip to see a Python script in action that automates the very attack we've been discussing.

To help you build your own scripts, the following articles provide commented Python code that you can study and adapt.

Method 2: Burp Suite Intruder

A common alternative to custom scripting is to use the powerful tools built into Burp Suite. The Intruder tool can be configured to automate our attack using a "Cluster Bomb" attack type.

The idea is to set two payload positions in our request:

1. The character index in the SUBSTRING function.
2. The character we are guessing.

Intruder will then iterate through all combinations. We can identify the correct characters by looking for responses that match our "true" condition (e.g., by filtering on response length or content).

The following video provides an excellent demonstration of this technique.

4. Advanced Optimization: Thinking Algorithmically

The brute-force approach (testing 'a', then 'b', then 'c'...) works, but it's inefficient. For a character set of 96 printable ASCII characters, you might make up to 96 requests per character you want to extract. We can do much better.

Since ASCII values are ordered, this problem is a perfect fit for a binary search algorithm. Instead of asking "Is the character 'a'?", you can ask, "Is the character's ASCII value less than 64?". Based on the true/false response, you can eliminate half of the remaining possibilities with each request. This reduces the maximum number of requests per character from ~96 down to just 7. This is not only faster but also stealthier, generating significantly less network traffic.

This is where your computer science background gives you a distinct advantage. Read the following section to see how to apply this optimization.

Conclusion

You have now tackled one of the most common and fundamental types of SQL injection found in the wild. While it requires more patience and precision than error-based or union-based attacks, mastering blind SQL injection is a mark of a skilled security professional.

Key Takeaways:

• The Condition: Boolean-based blind SQLi is possible when you can find a way to make the application respond differently to a true query versus a false one.
• The Technique: You extract data one bit at a time by asking the database a series of true/false questions, typically using the SUBSTRING function.
• The Tools: Manual extraction is impractical. Automation via Python scripting or Burp Suite Intruder is essential.
• The Optimization: Applying algorithms like binary search drastically improves the efficiency and stealth of your attack, separating a novice approach from an expert one.

Next Lesson Preview:
We've learned to deal with a "blind" scenario where we get a simple yes/no answer. But what if the application's response is exactly the same, regardless of whether your query is true or false? In our next lesson, we will explore time-based blind SQL injection, a technique where we introduce intentional delays into the SQL query and use the server's response time as our only indicator.