Skip to main content

🗂️PortSwigger Lab Writeup: Blind SQL Injection with Conditional Responses

Blind SQL Injection lab landing page showing lab details and objective


🎯 Objective

The objective of this lab is to exploit a Blind SQL injection vulnerability in a web application where the application executes a SQL query with tracking cookie in unsafe way to track the users for analytics and our goal is to extract the administrator password from the table users and log in as administrator.

  • Lab URL: https://portswigger.net/web-security/sql-injection/blind/lab-conditional-responses
  • Category: SQL Injection
  • Difficulty: Practitioner

💉 Payloads Used

1. For confirming blind SQL injection

  • Payload 1 - ✅
38GuobneQlpdcvg3' AND 1=1--

2. For determining database

  • Payload 2 - ✅
38GuobneQlpdcvg3' AND LENGTH(current_database())>0--

3. For confirming user table

  • Payload 3 - ✅
38GuobneQlpdcvg3' AND (SELECT 'a' FROM users LIMIT 1)='a'--

4. For confirming administrator in user table

  • Payload 4 - ✅
38GuobneQlpdcvg3' AND (SELECT 'a' FROM users WHERE username='administrator')='a'--

5. For determining password length

  • Payload 5 - ✅
38GuobneQlpdcvg3' AND (SELECT LENGTH(password) FROM users WHERE username='administrator')=#marker--

6. For determining password

  • Payload 6 - ✅
38GuobneQlpdcvg3' AND (SELECT SUBSTRING(password, ^POS^, 1) FROM users WHERE username='administrator')='^CHAR^'--

🧪 Exploitation Steps

🕵️Step 1: Observe the Website

  • Open the lab URL in your browser and explore its functionality. Initial inspection of the shopping website layout
    Login page of lab instance
  • Here, we can also see a Welcome back! message included in our web page.
  • At first glance, the website seems to be a shopping website with an option to filter products on different categories and also there is a login page. In the lab description, it is mentioned that the vulnerability is in the tracking cookie which is being used directly in a SQL query.
  • In the lab description, it is also mentioned that the application includes a Welcome back message if the SQL query is successfully executed, paving the way for blind SQL injection.

🔍Step 2: Find the Vulnerable Endpoint

  • Open the BurpSuite and send a request containing the TrackingId cookie to Repeater Tab by Ctrl + R Testing Blind SQLi with payload in BurpSuite Repeater
  • In the Repeater tab, we will first verify the endpoint for blind sqli by using the payload - 38GuobneQlpdcvg3' AND 1=1-- Successful Blind SQLi response with Welcome message confirming vulnerability
  • Hence, after sending this payload the response we got from the application included Welcome back message which means our payload executed successfully, revealing the vulnerable endpoint.

🧰Step 3: Determine the database

  • In order to further exploit the Blind sqli, we need to know which database is being used in the backend for crafting working payloads.
  • Since in our first payload for confirming the vulnerable endpoint which executed successfully, we used --, a comment sequence recognized by both PostgreSQL and Oracle, to ignore the remainder of the SQL query.
  • Now, we need to confirm which specific database it is from one of the above by first using a PostgreSQL database specific payload - 38GuobneQlpdcvg3' AND LENGTH(current_database())>0-- PostgreSQL-specific payload execution confirming backend database type
  • Hence, this payload executed successfully confirming that the application is using PostgreSQL database which will help in crafting working payloads.

🧾Step 4: Confirm the details

  • Before we directly extract the password, we should verify that if users table exists or not and if there is administrator username exists in the table.
  • We will use the payload - 38GuobneQlpdcvg3' AND (SELECT 'a' FROM users LIMIT 1)='a'-- for confirming that users table exists or not.
    info

    The LIMIT 1 clause is used in this payload to ensure that the subquery returns only a single value. Without it, if the subquery targets a table like users that has multiple rows, the database would throw an error saying that the subquery returned more than one row, which is not allowed in a comparison like ='a'. By using LIMIT 1, we restrict the subquery to fetch just one row, making the overall expression valid.

    Payload execution confirming existence of users table in database
  • Hence, the payload executed successfully confirming the presence of users table in database.
  • Now, we will use the payload - 38GuobneQlpdcvg3' AND (SELECT 'a' FROM users WHERE username='administrator')='a'-- for confirming whether the administrator user exists in the table. Payload confirms presence of administrator user in users table
  • Hence, this payload executed successfully confirming the presence of administrator record in users table.

📏Step 5: Determine the password length

  • Before we extract the password, it is essential to know the length of password of administrator so that we can craft the payload accordingly to extract it.
  • Now, to determine the length send the request to Intruder Tab by Ctrl + I
  • We will use the payload - 38GuobneQlpdcvg3' AND (SELECT LENGTH(password) FROM users WHERE username='administrator')=#marker-- where #marker will be replaced by the marker in Intruder.
  • We will use the Sniper attack where the Burpsuite will send the one payload at a time with different password lengths. Set the payload type to be a number and start range from 8 and end range to 22 as password is generally of 8-22 characters. BurpSuite Intruder setup to determine password length of administrator
  • After this, set the Grep-Match in Settings to only Welcome so that we can determine which request was successful and Finally, start the attack. Grep-Match configuration in BurpSuite Intruder for filtering Welcome responses
    Results showing successful request confirming password is 20 characters long
  • Hence, payload with 20 length was successfully executed as only the response of this request contains the Welcome back message.
  • Hence, it is being confirmed that the password is of 20 characters.

🔓Step 6: Extract the password

  • Here, I will be extracting the password using a extension in Burpsuite called Turbo Intruder which will fuzz the application very fast than normal Intruder in Burpsuite Community Edition.
    info

    Turbo Intruder is a Burp Suite extension designed for high-speed, customized HTTP request generation and analysis — ideal for blind SQLi brute-forcing.

  • Usually the default Intruder attack will take a very long time in community edition for this purpose, therefore we will be using Turbo Intruder.
  • Firstly, Install the Turbo Intruder extension from BApp Store.
  • Now, send a request containing the TrackingId cookie to Send to Turbo Intruder as show below. Sending HTTP request to Turbo Intruder for fast SQLi brute-force attack
  • We will use the payload - 38GuobneQlpdcvg3' AND (SELECT SUBSTRING(password, ^POS^, 1) FROM users WHERE username='administrator')='^CHAR^'-- for extracting password.
  • Use this script for making the requests to application and determining successful payloads. Since PortSwigger labs usually use lowercase alphanumerics in passwords, we limited the charset to a-z0-9 for speed.
    import string

    def queueRequests(target, wordlists):
    engine = RequestEngine(target.endpoint,
    concurrentConnections=3,
    requestsPerConnection=3,
    pipeline=False)

    max_len = 20
    charset = string.ascii_lowercase + string.digits

    for pos in range(1, max_len + 1):
    for ch in charset:
    req = target.req.replace("^POS^", str(pos)).replace("^CHAR^", ch)
    engine.queue(req)

    def handleResponse(req, interesting):
    if b"Welcome" in req.response:
    table.add(req)
  • After configuring everything, start the attack. Turbo Intruder output showing each extracted password character
  • Hence, we got the each password character of every place in 20 digit.

🧑‍💼Step 7: Log in as Administrator

  • Finally, open the login page and write the credentials of administrator extracted from Turbo Intruder to log in. Successful administrator login using extracted password credentials
  • And💥Booom!, We got the access of Admin account on the website. Admin panel access confirming lab completion and successful exploitation
  • And Finally, the Lab is solved.

🧠 Conclusion

  • This lab involves a case of SQL injection vulnerability, where the Tracking cookie parameter is used to track users for analytics and the application directly concatenates the cookie into a SQL query without validation or sanitization.
  • Since the application neither validates the user input nor uses prepared statements, it becomes vulnerable to SQL injection. This allowed us to manipulate the SQL query by injecting arbitrary SQL commands and gain full access to the database.
  • By systematically crafting and testing Blind SQLi payloads, we were able to:
    • Confirm the vulnerability using boolean-based payloads.
    • Identify the backend database (PostgreSQL).
    • Verify the presence of the users table and the administrator user.
    • Determine the password length of the administrator account.
    • Extract the password one character at a time using Turbo Intruder.
    • Finally, we used the stolen credentials to log in as administrator, gaining full access to the system.
  • This lab highlights the critical impact of even blind SQL injection vulnerabilities, and the importance of sanitizing all user input, including cookies.