2026-05-18

SQL Injection Walkthrough: Retrieving Hidden Data with Burp Suite

A practical walkthrough of a PortSwigger Web Security Academy lab. Using Burp Suite Proxy and Repeater to bypass a filter and retrieve unreleased products via SQL injection in a WHERE clause.

Overview

This is a hands-on walkthrough of the PortSwigger lab "SQL injection vulnerability in WHERE clause allowing retrieval of hidden data". The lab is part of the Apprentice path on Web Security Academy and is foundational practice on the way to the BSCP exam. Goal of this writeup is to document the methodology I use, not just the payload.

Environment

PortSwigger Web Security Academy lab on burpsuite-cdn.net. Tools used: Burp Suite Community Edition, Firefox configured to proxy through Burp on 127.0.0.1:8080. The lab is a fake e-commerce shop with category filters in the URL.

Step 1: Recon and Mapping the Application

Before touching anything, I browse the application normally with the Burp Proxy intercepting traffic in the background.

The shop has a category navigation bar at the top: Gifts, Pets, Tech gifts, etc. Clicking a category sends a GET request like:

GET /filter?category=Gifts HTTP/2
Host: lab-id.web-security-academy.net

This is the request I want to investigate. The category parameter is reflected directly into what looks like a SQL query in the backend.

Step 2: Identifying the Vulnerable Parameter

The lab description states the backend query is roughly:

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

Two things matter here. First, the category value is wrapped in single quotes. Second, the AND released = 1 filter is the reason hidden (unreleased) products are not shown. To solve the lab I need to break out of the quotes and neutralize that second condition.

Step 3: Sending the Request to Repeater

I right-click the filter request in Burp Proxy history and select "Send to Repeater". Repeater lets me modify and replay the request without re-clicking through the browser, which is how 90% of manual SQLi testing happens.

Step 4: First Payload, Comment Out the Rest of the Query

Easiest approach is to terminate the original string and comment out everything after it. In SQL this is done with -- (two dashes followed by a space).

Payload:

Gifts'--

In the URL, this needs to be encoded. The ' becomes %27 and the space after -- is %20:

GET /filter?category=Gifts'-- HTTP/2

Burp's Repeater handles URL encoding automatically when you right-click and pick "Convert selection → URL → URL-encode key characters", or you can just type the raw payload and let Burp send it.

The effective query becomes:

SELECT * FROM products WHERE category = 'Gifts'-- ' AND released = 1

Everything after -- is treated as a comment. The released = 1 filter is gone.

Step 5: Verifying the Result

The response in Repeater now contains products that were not visible before. Counting the items in the HTML body confirms the lab is solved. Burp shows a "Congratulations, you solved the lab!" banner in the response render.

Step 6: Alternative Payload, OR-Based Bypass

Comment-based termination is the cleanest, but the same goal can be reached with a boolean injection:

Gifts' OR 1=1--

This makes the query become:

SELECT * FROM products WHERE category = 'Gifts' OR 1=1-- ' AND released = 1

Because OR 1=1 is always true, the database returns every row regardless of category. Useful to know, but in a real assessment I would not use this on production traffic because it returns the entire products table and can trigger volumetric alerts in WAF logs.

Methodology Notes

A few things I take away from this lab that apply to harder SQLi labs further down the path:

  • Always confirm the injection point with a non-destructive payload first (a single quote alone is enough to trigger a syntax error response, which proves user input reaches the SQL parser).
  • Use Burp Repeater for iteration, not the browser. Browser tabs cache requests and you waste time.
  • Pay attention to the WHERE clause structure. Knowing whether your input is wrapped in quotes, parentheses, or numeric context changes the payload entirely.
  • Comment-out with -- is generic but fails on MySQL versions that require the space after --. UNION-based and stacked queries are the next steps when comments do not work.

Key Takeaways

  • Burp Proxy and Repeater are the minimum viable workflow for manual SQLi testing
  • The '-- pattern bypasses additional WHERE conditions when input is wrapped in single quotes
  • URL encoding is critical: untouched single quotes and spaces get mangled by the browser
  • The lab is intentionally trivial but the methodology scales: recon, identify parameter, isolate context, payload, verify
  • Next step on the PortSwigger path is SQLi in numeric context, then UNION-based extraction
← back to all writeups