Blind SQL Injection: An Expert’s Guide to Detect and Exploit

Blind SQL Injection Expert Guide to Detect and Exploit

Blind SQL injection, a stealthy and cunning form of SQL injection attack, poses a unique challenge for security professionals due to its elusive nature and difficulty in detection and exploitation. In this comprehensive article, we'll delve into the world of blind SQL injection, uncovering the subtle nuances that set it apart from other SQL injection attacks.

Throughout the article, we'll discuss various tools and methods, focusing on Kali Linux as our preferred platform, although you could use the tools mentioned in most OS. As we wrap up, we'll provide you with a set of tried-and-tested best practices for defending your web applications against these elusive and potentially damaging attacks. By the end of this article, you'll be well-versed in understanding, exploiting, and defending against blind SQL injection vulnerabilities.

Now, let's dive into this detailed guide and get you set up with the essential knowledge and techniques to effectively tackle the challenges posed by this type of vulnerability.

What Is Blind SQL Injection?

SQL injection is a prevalent web application vulnerability that occurs when an attacker manages to execute unauthorized SQL code on a web application's database. Attackers do this by inserting malicious SQL statements into user input fields, such as search boxes or login forms. When successful, an attacker can obtain sensitive information from the database, modify or delete data, and even execute administrative commands.

Blind SQL injection, a more concealed variant, happens when the attacker can't directly see the output of their injected queries. In this case, they need to deduce the results indirectly by using content-based or time-based techniques. This type of attack is used when the application does not visibly display the results of an injected SQL query, making it difficult for the attacker to confirm the success of their actions.

The benefit of using blind SQL injection over a standard SQL injection attack lies in its subtlety. Since the attacker doesn't directly view the output, it can be more challenging for security systems or administrators to detect the attack. The attacker often uses conditional responses (boolean-based) or delays in the application's response time (timing-based) to infer whether their injected SQL code has had the desired effect. 

By slowly and methodically gathering information about the database structure and content, an attacker can still exploit a blind SQL injection vulnerability to access sensitive data and manipulate the system without raising immediate suspicion.


We want to be absolutely clear on the importance of adhering to applicable laws regarding web application vulnerability scanning and exploitation. Before conducting any form of ethical hacking or penetration testing on a system, ensure that you have obtained explicit permission from the system or network owner.

Unauthorized hacking or scanning may seem trivial, but it can carry severe legal consequences, including fines or imprisonment, depending on your jurisdiction. Do not do it. Some of the laws that govern this activity include:

  • The Computer Fraud and Abuse Act (United States)
  • Sections 184, 342.1, 380, and 430 of the Criminal Code of Canada (Canada)
  • Computer Misuse Act 1990 (England)
  • Sec. 202a and 202b of the German Criminal Code (Germany)
  • Information Technology Act Sec. 43 and 66 (India)
  • The Act on the Prohibition of Unauthorized Computer Access (Japan)

If you doubt whether you’re acting in the clear, consult the agreement or scope of your authorized activities with a specific entity or review the code of conduct or disclosure guidelines with any of the bug bounty programs mentioned at the end of this article.

Discovering and Exploiting Blind SQLi

Now that you have a solid understanding of blind SQL injection and how it differs from regular SQL injection, let's dive into the process of discovering and exploiting these vulnerabilities. 

First, we'll guide you through setting up your lab environment, then go through testing for blind SQL injection manually, and finally use tools like SQLMap and Burp Suite to streamline the exploitation process.

Setting Up Your Lab

To start off, you’ll need to set up your lab to discover and exploit blind SQL injection vulnerabilities. There are several tools you can use, and we'll be using the following tools and resources:

Damn Vulnerable Web Application (DVWA): DVWA is an intentionally vulnerable web application that provides a safe environment for practicing various techniques. It comes pre-installed on Kali Linux or you can download it with sudo apt install dvwa. Once installed, set the difficulty level to “low” or "medium," and navigate to the "SQL Injection (Blind)" challenge. We'll use this to simulate a real-world scenario and demonstrate testing methods.

To start the DVWA application:

  1. Open the terminal and type the command: dvwa-start.
  2. If you’re not in the root account, you will be prompted to allow.
  3. The browser should automatically open to DVWA.
  4. (Alternatively) If it doesn’t open, go to the browser and enter: in the address bar.
  5. To stop the DVWA server, go back to the terminal and type the command: dvwa-stop.

SQLMap: This powerful open-source tool automates detecting and exploiting SQL injection vulnerabilities. It comes pre-installed in Kali Linux, so if that’s the OS you’re using, you don't need to download it separately. We'll use SQLMap to automate the exploitation of the discovered blind SQL injection vulnerability in DVWA.

Burp Suite: Burp Suite is a widely-used web application security testing toolkit. For this article, we'll use the Community Edition, which comes pre-installed on Kali Linux. This will be used to intercept requests made to the DVWA. We'll demonstrate an alternative method of testing with SQLMap by capturing a request with Burp, saving it as a text file, and then running it through SQLMap.

It’s recommended that you only run DVWA or other intentionally vulnerable applications in a virtual environment. In How to Install Kali Linux on VirtualBox & Start Hacking Now you can learn how.

If you need a more in-depth, step-by-step guide check out How to Create a Virtual Hacking Lab: The Ultimate Hacker Setup.

Testing for Blind SQL Injection

Detecting blind SQL injection involves sending queries that produce conditional responses or delay the server's response time. We’ll guide you through each process step so you can thoroughly test for blind SQL injection and understand the reasoning or behavior behind each action.

As a note, the exact query structure or commands may vary depending on the DB used. Demonstrated is MySQL.

Step 1: Normal response

Start by submitting a normal response, such as entering '2', to see how the application behaves under regular circumstances. This helps establish a baseline for the expected behavior without injected SQL code.

Normal response

Step 2: Simple test

Perform a simple test by entering a single quote (2‘#) after the '2' to check if this might indicate a potential vulnerability in the web application. If an error occurs or the behavior changes, it could suggest that the application is improperly handling user input and may be susceptible to SQL injection. This () isn’t required in all cases and may vary by the DB you’re testing on.

NOTE: When testing within a form field, you need to place a # at the end of your query to comment out any text the program might add afterward.

Simple test
Testing for SQL Injection Vulnerability

Step 3: True/False test

Conduct the true/false tests by injecting "2’ AND 1=1#" (always true) and "2’ AND 1=0#" (always false) conditions, and observe the application's responses to both queries. If the application's behavior changes based on the truthfulness of the injected condition, it indicates that the SQL code is being executed, confirming the presence of a vulnerability. 

In a regular SQL injection attack, this true condition could return additional information from a table, but that’s not the case in a blind attack. Again, you’re looking for changes in the response.

TrueFalse test
The result of 1=1, an intentionally true condition.
TrueFalse test
The result of 1=0, an intentionally false condition.
Regular SQLi vs Blind SQLi

Step 4: Timing-based test

Test the timing-based method by introducing "2’ AND SLEEP(5)#" to the query. Compare the response time with and without the sleep command. A noticeable delay indicates a potential vulnerability, as it demonstrates that the application is executing the injected SQL command and waiting for the specified time before returning a response.

Timing-based test
Running the timing-based attack.
Timing-based attack complete
Timing-based attack complete.

Step 5: Determine columns

Determine the number of columns in the database using the "2’ ORDER BY X#" condition, where X is the number of columns we’re testing for. Increment the number until the application's behavior changes, signifying you've found the correct length. This step is essential for understanding the database structure, which can be useful when exploiting the vulnerability.

Manual testing for column length of 1
Manual testing for column length of 1.
Manual testing for column length of 2
Manual testing for column length of 2.

In our case, the web application threw an error when we tested for a column length of 3. This change in behavior let’s us know that we’ve identified the correct number of columns is 2, since that was the last successful test before the change. This is learned by watching for the change in response. 

Step 6: Determine the length of DB

Next, we’ll demonstrate the "2’ AND LENGTH(DATABASE())=X#" condition, where X is the number of characters being tested. This can be used to determine the length of the database name. We’ll use the same approach as we just did to determine the number of columns, except this time, we’re trying to elicit the number of characters in the DB name. To do this, we’ll test by character length in an iterative manner.

Testing for a character length of 1
Testing for a character length of 1.
Finally, a change indicates a DB name length of 4
Finally, a change indicates a DB name length of 4.

This can also be performed with a sleep command in cases where a visual indicator isn't available. For example, use "2’ AND LENGTH(DATABASE())=X AND SLEEP(5)#" where X is the suspected length of the database. If the application's response is delayed by the sleep command, it confirms the correct length of the database.

id 2 and Length Database and Sleep

Step 7: Determine the database name

Finally, we can start enumerating the actual name of the database. We already know that it’s four characters long, but we can do more by determining what those characters are. To do this we’ll be going through testing different ASCII characters by using 2’ AND ASCII(SUBSTR(DATABASE(),X,X))>YY#. In this case X is the character position we’re testing for, and YY is the ASCII character decimal.

With this method you’re asking the database if the first character is greater than a set letter. If it’s not, it will respond with a negative. We’ll start somewhere near the middle of the lowercase alphabet with “l” (which is ASCII decimal 108). So the query looks like: 2’ AND ASCII(SUBSTR(DATABASE(),1,1))>108#.


Based on the response, know that the first character is not greater than “l” so we have to change the operation to ask if it’s less than “l”. We do this be changing the query to 2’ AND ASCII(SUBSTR(DATABASE(),1,1))<108#.

Determine the database name
Determine the database name

Based on this response, we now know that the first letter is somewhere between lowercase “l” and all preceding ASCII characters. Technically, this does include all uppercase, numbers, and special characters. Knowing this we can begin to test incrementally until we see a change in the response. In our case, we see a changed response once we enter 100.

preceding ASCII characters
preceding ASCII characters

This is now telling us that the character is not less than a lowercase “d”. We can confirm that this is the correct letter by reversing the query.

preceding ASCII characters
preceding ASCII characters

We have successfully confirmed the first character. Now, we can use this same method by changing the query to the second character placement and repeating this all over again. We’ll be sure to change the placement by entering 2’ AND ASCII(SUBSTR(DATABASE(),2,2))<108#.

preceding ASCII characters
Vulnerability SQL
With this result, we know that the second character is greater than lowercase “l”.

By now, you should understand the rationale behind each step. By observing the application's behavior in response to various injected SQL commands, you can effectively identify and comprehend blind SQL injection vulnerabilities.

In the next section, we'll demonstrate how to exploit these vulnerabilities with the help of SQLMap. Keep practicing these techniques in a controlled environment to sharpen your skills and become an expert in detecting and exploiting blind SQL injection attacks.

Example 1: Exploiting Blind SQL Injection

Now that we’ve confirmed the vulnerability, we’ll go through the steps to exploit it using SQLMap. Pay attention to the screen captures at each step for better understanding. Even better, follow along to really cement the process and learning in your mind and grow this skill.

There are many powerful ways to use SQLMap, and we’ll only cover a few here. You can reference Sqlmap Cheat Sheet: Commands, Options, and Advanced Features for more great commands.

Step 1: Familiarize with SQLMap

Open the SQLMap help page to familiarize yourself with the type of information required for an attack and the command structure of the tool. Specifically, we will see that we can use a URL with the -u flag and the cookie information with the --cookie= flag.

sqlmap -h

Familiarize with SQLMap

Step 2: Retrieve session information

Gather the required cookie and security level from the browser's Developer Panel out of the Storage tab.

Retrieve session information

Step 3: SQLMap URL command

Execute SQLMap with the -u and --cookie= information. Review the resulting information, which includes the parameters, payload, and location of the output files.

SQLMap URL command
SQLMap executing URL attack.
Return of parameters and output location
Return of parameters and output location.

Step 4: Open session file

Now we’ll go to the terminal and navigate to the output file location. First, we’ll use it to see what files we have to work with. Use sqlitebrowser to open the session.sqlite file.

Open session file

Step 5: DB Browser

In the sqlitebrowser, examine the database structure and browse the data tabs.

DB Browser
Viewing the “Database Structure” tab in DB Browser.
Viewing the “Browse Data” tab in DB Browser
Viewing the “Browse Data” tab in DB Browser.

Step 6: View target file

Go back to the terminal and use cat target.txt to view the file, which contains the command you used.

View target file

Step 7: View log

Use cat log to view the contents of the log. This includes the same parameter and payload information we saw earlier, as well as details about the database and web application technology. All of this information could be useful in any follow on penetration testing we might conduct in later stages.

View log

Step 8: SQLMap URL with database name flag

Now we’ll go back to the terminal and execute the same command in SQLMap, but this time append '--dbs' to discover the database name. We know it’s four characters long from our earlier manual testing, but we want to know more about this database.

SQLMap URL with database name flag
And there it is, “dvwa”!

Step 9: SQLMap URL with column flag

Next, we want to elicit the user columns with the flags -D dvwa -T users --columns. This will provide you with a lot more information about what’s actually inside the database.

SQLMap URL with column flag
SQLMap URL with column flag

Step 10: SQLMap URL with user dump flag

Now we get to the good part, use -T users --dump to extract data from the user's table. Review the response and note how SQLMap prompts you to crack the hash of the passwords it discovers and then presents the results in a neat, orderly table for you.

SQLMap URL with user dump flag
SQLMap URL with user dump flag
Here it’s going through the database and pulling user information.
SQLMap offers to crack the password hashes. Yes, please!
SQLMap offers to crack the password hashes. Yes, please!
SQLMap offers to crack the password hashes. Yes, please!

Note the neat arrangement of the information in the picture above. In addition to just cracking the passwords and placing them in a tidy table, SQLMap also automatically outputs that information to a .csv file. This can then be fed into other tools for further exploits during a penetration testing case.

Example 2: Exploiting Blind SQL Injection With HTTP Data

Now we'll demonstrate an alternative method of exploiting blind SQL injection using SQLMap and HTTP data gathering from Burp Suite.

Step 1: Intercept traffic with Burp Suite

Open Burp Suite, which you've configured to capture HTTP traffic. Then navigate to the Proxy tab, and locate the query submission in the HTTP history.

Intercept traffic with Burp Suite

Step 2: Send request to repeater

In the Request panel, right-click on the query submission and select 'Send to Repeater'.

Step 3: Copy raw data from Burp Suite

Switch to the Repeater tab, and copy the raw request data from the panel.

Copy raw data from Burp Suite

Step 4: Create request file

Paste the raw request data into a new file that you'll use with SQLMap. In our example, we named this file request.

Create request file

Step 5: SQLMap load HTTP request file

Return to the terminal and run the command sqlmap -r request. The -r flag tells SQLMap to parse and use the raw HTTP request from the specified file.

SQLMap load HTTP request file

As in the previous method, SQLMap will offer to crack the discovered user password hashes once it has extracted the data.

SQLMap load HTTP request file

This method provides an alternative to manually inputting cookie and URL information in the command line, streamlining the process using captured HTTP traffic. As in the previous methods, this information is output to your directory and can be studied or used for future efforts.

Defending Against Blind SQL Injection

By following best practices and guidelines recommended by reputable organizations like OWASP, NIST, W3, and Amazon AWS, you can significantly strengthen your application's defenses against these attacks. StationX also provides valuable information regarding the potential vulnerabilities and corresponding remediations for web applications and other connected systems. 

These organizations provide valuable resources and information that cover a wide range of topics, including secure coding practices, database security, web application defenses, and monitoring and incident response. In this section, we'll explore these best practices in detail, providing you with actionable steps to help safeguard your web application from blind SQL injection vulnerabilities.

Secure coding practices

Implementing secure coding practices is crucial to defending against blind SQL injection attacks. OWASP recommends using prepared statements or parameterized queries to separate user input from SQL code, reducing the risk of injection. Additionally, incorporating input validation techniques, such as whitelisting, helps restrict the types of data that can be entered by users, further enhancing security.

Database security

Database security measures are essential in minimizing the potential impact of an attack. Limiting database user privileges ensures that attackers cannot gain access to sensitive information or perform unauthorized actions. Regularly updating and patching your database management system helps address known vulnerabilities, making it more difficult for attackers to exploit them. You can read more about this in NIST SP 800-44 version 2 (Section 6.4.2 specifically discusses this).

Web application defenses

Implementing web application defenses, such as a web application firewall (WAF), can help detect and block SQL injection attempts. Amazon AWS discusses how a WAF analyzes incoming traffic and filters out malicious requests through database managed rule groups, reducing the likelihood of a successful attack.

Monitoring and incident response

Monitoring and logging application activity is vital for identifying suspicious activity and detecting potential attacks early on. NIST recommends establishing a robust logging and monitoring system, along with a well-defined incident response plan, ensuring quick and effective responses to security incidents.


Throughout this article, we've dug deep into blind SQL injection, exploring its unique characteristics and the techniques used to discover and exploit these vulnerabilities. From setting up a testing environment with DVWA and Kali Linux to conducting manual tests and utilizing tools like SQLMap and Burp Suite, we've armed you with practical guidance and actionable advice to skill up on this complex subject. 

Moreover, we've emphasized the importance of implementing robust security measures such as secure coding practices, database security, web application defenses, and monitoring and incident response to safeguard against blind SQL injection attacks.

As we've demonstrated, blind SQL injection is a formidable challenge in cyber security for web applications, but with the right knowledge and skill set, you can effectively defend against these threats. Continue your learning by taking these courses to bolster your aptitude in web application ethical hacking and defense:

Frequently Asked Questions

Level Up in Cyber Security: Join Our Membership Today!

vip cta image
vip cta details
  • Andrew DeVito

    Andrew is a Content Writer at StationX. He comes from a multi-discipline professional background with over 20 years of combined experience in healthcare compliance, financial cyber security regulations, wireless and mobile security, and threat modeling. He is dedicated to translating complex technical concepts into an easily understandable language to help you successfully navigate the ever-evolving landscape of cyber threats.

  • david says:

    i like your articles

  • >