Day 14: Blind SQL injection with time delays — Zero to Hero Time-Based Blind SQL Injection

Hi, my fellow hackers. This is Rayofhope. I have over 5 years of experience and am currently working as a consultant with a Big 4 firm.

It’s Day 14 of posting all the PortSwigger labs, not just the solutions. I’ll break down why we take each step, because once the ‘why’ is clear, the ‘how’ becomes easy.

Let’s Start:

Before you go for this blog, make sure to read the Previous one

Link to Previous Blog: https://arayofhope7.medium.com/day-13-visible-error-based-sql-injection-zero-to-hero-blind-injection-portswigger-3da2241a1672

Video Walkthrough — You can watch the video or read the blog, totally up to you. But if you ask me, start with the video, then read the blog to connect all the dots.

Note:

Time-based SQL Injection is a subtype of blind SQL injection where the attacker determines the presence of a vulnerability based on the time the database takes to respond. Based on the response time, the attacker can determine whether a condition is true or false and exploit the vulnerability.

Each database management system (DBMS) has its own built-in function to pause execution, so the payload used in time-based SQLi varies depending on the backend.

MySQL: select sleep(10)
MSSQL: waitfor delay ‘0:0:10’
PostgreSQL: select pg_sleep(10)
Oracle: dUbms_pipe.receive_message((‘a’),10)

Lab Questions: This lab contains a blind SQL injection vulnerability. The application uses a tracking cookie for analytics and performs a 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.

To solve the lab, exploit the SQL injection vulnerability to cause a 10-second delay.

Objective:
What is the database
What kind of payload will be used for that database?
Delayed response time by 10 seconds.

This is how the lab looks — let’s intercept the data.

Request was intercepted and sent to the repeater

This is how the response looks:

We have one parameter here, which is ‘Tracking ID’. Let’s see if it is vulnerable to SQL injection.

I tried to break the query using a single quote ('), but it's returning a 200 OK response. This could mean that the developer's code does not use single quotes around the parameter.

I tried using a double quote ("), a single quote ('), a single quote with a closing parenthesis (')), and a double quote with a closing parenthesis (")), but in every case, the response returned 200 OK.

This suggests that the application may not be vulnerable to UNION or error-based SQL injection attacks. Let’s try going for a blind SQL injection instead.

As we now know that the application is vulnerable to time-based blind SQL injection, we will proceed by injecting time-based blind SQL payloads.

I tried using a time-based payload for MSSQL, and although it returned a 200 OK response, the response time didn’t change. This suggests that the application might not be using an MSSQL database.

Used a PostgreSQL time-based SQL injection payload ' || (SELECT pg_sleep(10))--, and the response was delayed by 10 seconds. This confirms that the application is vulnerable to time-based blind SQL injection and is using a PostgreSQL database.