Blind SQL Injection - Timebase SQL Injection

Questions and Answers

#

1. What distinguishes Time-Based SQL Injection from other SQL injection techniques? Explain how an attacker can use time delays in SQL queries to extract information from a database, and why this method is particularly useful when dealing with blind SQL injection scenarios where no data is returned in the web application’s responses.

   Time-Based SQL Injection is an SQLi technique that relies on the server’s response delay instead of directly returned data.

   Key differences:

   • In Union-Based SQLi, the attacker attempts to display extracted data directly on the page.
   • In Error-Based SQLi, the attacker relies on SQL error messages.
   • In Boolean-Based Blind SQLi, the attacker observes differences between true and false responses.
   • In Time-Based Blind SQLi, the attacker observes whether the response is fast or delayed to infer data.

   The exploitation method is as follows: the attacker injects a condition into the SQL query. If the condition is true, the database is forced to “sleep” for a few seconds; if it is false, the response is returned normally. For example, conceptually:

   1 2	IF condition is true THEN delay 5 seconds ELSE return immediately

   If the website responds slowly, the attacker can infer that the condition is true. By repeating this process character by character, the attacker can gradually extract the database name, table names, column names, or sensitive data.

   This method is particularly useful in Blind SQL Injection because the application does not display data, does not return errors, and the visible responses may look the same. In this case, response time becomes a “side channel” for leaking information.

2. Describe the process of executing a Time-Based SQL Injection attack on a vulnerable web application. What are the key steps in crafting a SQL query that causes a deliberate delay in the database response.

   1. Identify an input point that may be vulnerable to SQLi, such as a URL parameter, login form, search box, cookie, or header.
   2. Test whether a delay can be triggered by injecting an SQL expression that causes the database to pause its response, such as SLEEP(), pg_sleep(), or WAITFOR DELAY, depending on the database management system.
   3. Compare the response time:
   • If a normal request responds within 1 second.
   • If a suspected SQLi request responds after 5–10 seconds.
   • Then the application may be executing the injected SQL payload.
   4. Create a true/false condition combined with a delay, for example:

   1 2	If the condition is true → delay for 5 seconds If the condition is false → no delay

   5. Extract data step by step by asking true/false questions, for example:
   • Is the database name length equal to 5?
   • Is the first character “a”?
   • Is the second character “d”?
   6. Repeat the process until the required data is inferred.

Practice

#

1. First, we access the Blind SQL injection with time delays lab on PortSwigger Web Security Academy. After opening the lab, the website displays a shopping interface with product categories such as All, Food & Drink, Gifts, Lifestyle, Tech gifts, and Toys & Games.

The objective of this lab is to exploit a Blind SQL Injection vulnerability using the Time-Based SQL Injection technique. This means deliberately causing the database to respond slowly in order to confirm that the injected SQL statement has been executed.

2. After launching Burp Suite and configuring the browser to route traffic through Burp’s proxy, we access any category on the website, for example:

1

GET /filter?category=Toys+%26+Games HTTP/2

Burp Suite captures the request sent to the server. In this request, we can see that there is a TrackingId cookie. This is a user-controlled value and may be used by the application in a backend SQL query.

Example of the cookie section in the request:

1

Cookie: TrackingId=<tracking_id_value>; session=<session_value>

After that, we send this request to the Repeater tab so that we can modify the payload and resend the request multiple times to observe the server’s response.

3. In Burp Repeater, we focus on testing the TrackingId cookie parameter because this is commonly used by applications to track users and may be stored or queried in the database.

The exploitation idea is to append an SQL payload to the end of the TrackingId value. If the backend executes this SQL payload, the database will be instructed to “sleep” for a certain period of time before returning a response.

4. Since each database management system uses a different delay syntax, we test multiple payload formats to determine which database backend is being used.

Payload for SQL Server

1

'||WAITFOR DELAY '00:00:05'--

This payload uses the WAITFOR DELAY syntax, which is commonly used in Microsoft SQL Server. However, after sending the request, the response time is only a few hundred milliseconds and there is no significant delay. Therefore, we can conclude that the backend does not process the payload using SQL Server syntax.

Payload for MySQL

1

'||sleep(10)--

This payload uses the sleep() function, which is commonly used in MySQL. After sending the request, the response is still returned very quickly, without the expected 10-second delay. This indicates that the MySQL-style payload is not suitable for the backend of this lab.

Payload for PostgreSQL

1

'||pg_sleep(10)--

This payload uses the pg_sleep() function, which is used to create a delay in PostgreSQL. When this payload is inserted into the TrackingId cookie and the request is sent, the server responds with a clear delay of more than 10 seconds. This indicates that the payload has been successfully executed by the database.

5. Payload analysis

1

'||pg_sleep(10)--

Meaning of the payload:

• The ' character is used to close the current string in the SQL query.
• The || operator is used for string concatenation in PostgreSQL.
• The pg_sleep(10) function instructs the database to pause processing for 10 seconds.
• The -- sequence is used to comment out the rest of the SQL query to avoid syntax errors.

When the server responds slowly after this payload is sent, it proves that the TrackingId cookie value has been inserted into an SQL query without being handled securely. Since the application does not return database data or SQL error messages, we rely on the response time to confirm the vulnerability. This is the key characteristic of Time-Based Blind SQL Injection.

6. After sending the request containing the successful PostgreSQL payload, Web Security Academy displays the Solved status and shows the success message:

Conclusion:

Through this practical exercise, we identified that the application has a Blind SQL Injection vulnerability in the TrackingId cookie. Since the application does not display data directly and does not return SQL errors, we used the Time-Based SQL Injection technique to test it. The successful payload is:

1

'||pg_sleep(10)--

When the payload is executed, the server responds with a clear delay, proving that the injected SQL statement has been processed by the database. This is evidence that the application has not used secure query mechanisms such as prepared statements or parameterized queries.