How Hackers Use Time-Based SQL Injection to Extract Sensitive Data from Databases
What if just a few seconds of delay were enough to extract sensitive data from a system? An attacker doesn't always need direct access to data to exfiltrate an entire database. Simply measuring response times can be enough.
In What the Hack, our ethical hackers share remarkable vulnerabilities discovered during anonymous penetration tests. This gives developers insight into how vulnerabilities are exploited in real-world scenarios and, more importantly, how to prevent them. In this edition, Daan demonstrates how he used Time-Based SQL Injection to gain access to a database and explains how developers can identify and prevent this vulnerability.
Exploring the Application
I conducted the penetration test on an application that processed highly sensitive personal data. As with every assessment, I began by performing reconnaissance on the application to gain a better understanding of how it worked.
To analyze the web traffic, I used Burp Suite Professional. For penetration testers, Burp Suite is like a Swiss Army knife: it allows you to intercept, manipulate, analyze, and automatically scan web traffic for vulnerabilities.
Automated scans are a valuable starting point, but they are only a tool. They identify potential issues, while it remains the tester's responsibility to verify whether a reported finding is actually exploitable.
A Suspicious Finding: Time-Based SQL Injection
During the scan, the endpoint responsible for generating annual statements was flagged with a "SQL Injection" finding.
We encounter these types of findings regularly during penetration tests, and they often turn out to be false positives. For example, a server may respond more slowly due to high load, causing an automated scanner to mistakenly identify a vulnerability. Even so, I decided to investigate this finding further.
What is Time-Based SQL Injection?
One way to detect a SQL injection vulnerability is by looking for delays in database query execution.
Nearly every database provides functions that can temporarily pause the execution of a query. Developers sometimes use these functions to test how an application behaves when database operations take longer than expected. However, attackers can abuse the same mechanism.
By modifying a query so that the database intentionally waits a few seconds before responding, an attacker can determine whether user input is being incorporated into the SQL query. If the application's response time consistently matches the specified delay, it is a strong indication that the input is reaching the database query and may be vulnerable to SQL injection.
Confirming the Vulnerability
To verify the finding, I duplicated the HTTP request that triggered the alert and modified it. Instead of introducing a 3-second delay, I changed the payload so the database would pause for 50 seconds before responding.
This helped rule out the possibility that the delay was simply caused by server load. The response arrived exactly 50 seconds later, confirming that the application was indeed vulnerable to Time-Based SQL Injection.
From vulnerability to database access
Although it is possible to extract data manually using time-based SQL injection, the process is extremely slow. Instead, I used sqlmap, an open-source tool that automates the entire process from detection to exploitation. By issuing a series of time-based queries, sqlmap can gradually reconstruct the contents of a database.
The result? Full access to a database containing data from more than 1,200 organizations. The database also stored highly sensitive personal information, including national identification numbers (BSNs), address details, and user information.
Further analysis revealed that three different parameters within the application were vulnerable to SQL injection. However, exploiting just one of those parameters was enough to gain complete access to the database.
How Could This Have Been Prevented?
The vulnerability could have been prevented relatively easily by using prepared statements (also known as parameterized queries).
Prepared statements ensure that:
- user input remains separate from the SQL query structure
- user input cannot be interpreted as SQL syntax
As a result, attackers cannot inject additional SQL commands, keeping the database query secure.
Automated Scans Are a Starting Point, Not the End Goal
The vulnerability was initially detected by an automated scanner. Without manual verification, the finding could easily have been dismissed as a false positive. Automated scanners identify anomalies, but it is the tester who determines whether a finding represents an actual, exploitable vulnerability.
For organizations, this once again highlights the importance of:
- secure input validation
- using prepared statements (parameterized queries)
- thorough penetration testing
Sometimes, a single vulnerable parameter is all it takes to expose an entire database.
