PortSwigger Lab: SQL Injection Vulnerability in WHERE Clause Allowing Retrieval of Hidden Data

Target: PortSwigger Web Security Academy

Objective

The goal of this lab is to exploit a SQL injection vulnerability in the product category filter to display one or more unreleased products that are normally hidden from the user.

The Vulnerability Concept

When a user selects a product category on this application, the backend executes a database query that looks like this:

SELECT * FROM products WHERE category = ‘Gifts’ AND released = 1

SELECT * FROM products WHERE category = ‘Gifts’ AND released = 1

The vulnerability exists because the application concatenates user input directly into the category parameter without proper sanitization or parameterized queries. By injecting SQL syntax into this parameter, we can manipulate the logic of the WHERE clause to bypass the AND released = 1 restriction.

Tools Used

• Browser Proxy: FoxyProxy configured to route traffic to 127.0.0.1 on port 8080.

• Interceptor: Burp Suite Community Edition.

Step-by-Step Exploitation

1. Environment Setup & Reconnaissance

To begin, I enabled the Burpsuite profile in FoxyProxy to capture the application's HTTP traffic.

Browsing to the main page of the application reveals a standard e-commerce storefront with a category filter. I clicked on the Accessories category to observe how the application handles filtering. The URL updated to include the query parameter:

.../filter?category=Accessories

At this stage, the page only displayed three released items in the Accessories category.

2. Traffic Interception

I switched over to Burp Suite and checked the HTTP history tab under the Proxy tool. Here, I located the specific GET request made to the /filter?category=Accessories endpoint.

3. Payload Crafting in Repeater

I sent this GET request to Burp Repeater (Ctrl + R) to rapidly test different inputs. To manipulate the database query, I crafted the following SQL injection payload:

‘+OR+1=1--

‘+OR+1=1--

I injected this into the request so the first line read:

GET /filter?category='+OR+1=1-- HTTP/2

How the payload works:

• ' closes the string opened by the application's query.
• OR 1=1 injects a condition that always evaluates to true, forcing the database to return all items regardless of their category.
• -- comments out the remainder of the original query (specifically the AND released = 1 check), ensuring unreleased items are also returned.

4. Execution and Proof

Sending the modified request in Repeater resulted in an HTTP/2 200 OK response.

To verify the visual impact on the frontend, I applied the URL-encoded payload directly in the browser:

.../filter?category=%27+OR+1=1--

The application successfully executed the injected query, revealing additional hidden products and displaying the "Congratulations, you solved the lab!" banner at the top of the page.

Remediation

To defend against this type of SQL injection, developers should avoid concatenating user input directly into database queries. Instead, the application should use prepared statements (parameterized queries) provided by the web framework's database driver. This ensures that user input is always treated strictly as string data, rather than executable SQL code.

This write-up is part of my ongoing PortSwigger Web Security Academy lab series. You can find the raw markdown files, payloads, and my full progress tracker in my Github Repository.