Learning Web-Sec - Day 7 - PortSwigger SQL Injection Labs

Time Delays and Information Retrieval

Now that we know that we can cause delays with SQL injection in Blind SQL Injection vulnerabilities, We can delay the response using conditions which can help us extract information from database. Let’s see how.

Lab 13 — Blind SQL Injection with Time Delays and Information Retrieval (Link)

Level: Apprentice

Description of Lab:

This lab contains a blind SQL injection vulnerability. The application uses a tracking cookie for analytics, and performs an SQL query containing the value of the submitted cookie.

The results of the SQL query are not returned, and the application does not respond any differently based on whether the query returns any rows or causes an error. However, since the query is executed synchronously, it is possible to trigger conditional time delays to infer information.

The database contains a different table called users, with columns called username and password. You need to exploit the blind SQL injection vulnerability to find out the password of the administrator user.

To solve the lab, log in as the administrator user.

Let’s get straight to editing the intercepted requests.

As we can see, the response typically takes nearly 1135 milliseconds, which is about 1.1 seconds.

Let’s first try to find what database we are working with non-conditional payloads. That is we won’t try finding the password from the first try of injecting SQL. Later we’ll try conditional payloads for extracting the administrator user's password.

The first one didn’t work. Let’s move on with our payloads till we get the delayed response.

We got the time delay. Congratulations, now we know that the database used. is PostgreSQL and we know what payload to use for using conditional statements to retrieve the administrator’s password.

Let’s see how the substring function works in PostgreSQL.

SUBSTRING(password, 1, 1)=‘a’ will check if the

Now let’s try fuzzing for the first position of the password of administrator and the edited payload would look something like :

Here we’ll try fuzzing the character ‘a’ for finding if this payload works.

And we can see a time delay in the requests. I know there are 2 requests that have time more than 10 seconds. But If we look at it closely one took 10.23 and the other one took 10.83 seconds. And typical response time of fuzzing requests is near .7-.8 seconds, So if the statement is true, the total time should be more than (typical response time + delay), that is more than 10.7 seconds. And only one value has the response time greater than the calculated time.

And we successfully extracted the length of the password, Now we can start the fuzzing for further exploitation.

Let’s start the fuzzer and this lab will take more time than the previous labs as there are 20 conditions which will give true and we’re going to get a time delay of 10 seconds.

Here we can reduce the “Concurrent Scanning Threads per Scan” to 1 for more accurate results. If we scan for multiple requests concurrently, what happens is all the requests are sent together and the next requests will get responded with after the request with the delay too.

And we have our password built up, log in with it. Also you need to

And we’re done with the lab. Congratulations. And we’ve successfully completed the SQL labs, I mean I know we have a few labs of SQL Injection section remaining but they have concepts from other vulnerabilities, so we will cover them after learning the concepts of those vulnerabilities.

So, I’ll be back again with a new vulnerability next time. I guess I’ll be taking a small break from Web Sec and try some other things, Maybe new languages. But I’ll keep you updated with my blogs.

I hope my blogs help.