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

Challenge Overview

This lab contains a SQL injection vulnerability in the product category filter. When the user selects a category, the application carries out a SQL query like the following:

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

The goal of the lab is to perform a SQL injection attack that causes the application to display one or more unreleased products.

• Exploiting the SQL Injection
• Understanding the Query

The SQL query is filtering products based on the category chosen by the user, and it only displays products that are marked as released. The vulnerability exists because the category value is not properly sanitized, allowing an attacker to inject malicious SQL code. Strategy

To exploit this, we can inject a condition that forces the query to ignore the released = 1 filter. By injecting the following payload:

' OR 1=1--

The SQL query becomes:

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

How to Perform the Attack

1. Start Burp Suite
   Open Burp Suite and browse to the lab provided by PortSwigger.

2. Activate Proxy Interception
   Once Burp Suite is running, navigate to the “Proxy” tab. Press the “Intercept is off” button to activate the intercept function. You will see the button change to “Intercept is on.”

3. Enable Proxy in the Browser
   In your browser, enable the proxy either through settings or by using a plugin. We choose the latter option for simplicity.

4. Ensure Interception is Active
   With “Intercept is on” and your browser using the proxy, you are ready to start the attack.

5. Navigate to the ‘Gifts’ Category
   On the website, navigate to the “Gifts” category in the navigation bar. You will see that Burp Suite intercepts the request.

6. Analyze the Request
   Let’s take a closer look at this request.

7. Identify the Line to Manipulate
   In the first line of the GET request, we can see the destination we are navigating to. This is the line we can manipulate. Let’s go ahead and do that.

8. Send the Request to the Repeater
   To manipulate the request more easily and make multiple attempts, send this request to the Repeater tab.

9. Analyze a Normal GET Request in Repeater
   Now that we’re in the Repeater tab, let’s examine what a normal GET request to the “Gifts” category looks like in the response.

As you can see, there are three gifts available for purchase as a consumer on the webshop.

1. Testing for SQL Injection
   We know that we can check if SQL injection is possible by appending the following syntax: '+OR+1=1--. Let’s go ahead and test this.

2. Check the Output in the ‘Render’ Tab
   After sending the request, switch to the “Render” tab to check the output and see if the SQL injection was successful.

3. Observe the Additional Items
   As you may notice, additional items have appeared in the response. This confirms that the SQL injection was successful.

4. Complete the Lab
   Go back to the “Proxy” tab and turn off the intercept by pressing the “Intercept is off” button. In your browser, you will now see that the first lab has been completed successfully.

Additional Notes

• Why does OR 1=1 work?
  The condition 1=1 is always true, which means the SQL query will return all rows, effectively bypassing the released = 1 condition.

• Why use --?
  The -- is used to comment out the rest of the SQL query, so the application ignores anything after the injection.

Lab 2: SQL Injection Vulnerability Allowing Login Bypass

Challenge Overview

This lab contains a SQL injection vulnerability in the login function. The objective is to perform a SQL injection attack that logs into the application as the administrator.

Exploiting the SQL Injection

Step 1: Understanding the Login Functionality

Once the lab is loaded, navigating to “My Account” presents us with a login window requiring a Username and Password. Based on the lab description, we know there is an administrator user in the system.

Step 2: Initial Login Attempt

We begin by attempting to log in with:

• Username: administrator
• Password: password

At this point, we intercept the login request using Burp Suite and inspect the data being sent to the server.

Step 3: Testing for SQL Injection

By analyzing the intercepted request, we observe the structure of the SQL query behind the login process. Since the input fields are vulnerable, we can inject malicious SQL code to bypass authentication.

Our injection payload will be:

administrator'--

Step 4: Modifying and Forwarding the Request

After applying the SQL injection payload to the intercepted request, we forward the request. Upon successful submission, we are logged in as the administrator.

Additional Notes

• Why does administrator'-- work?
  The payload administrator'-- effectively manipulates the SQL query by closing the current string and commenting out the rest of the query. This bypasses the need for a valid password, allowing unauthorized access.

• Why use --?
  The -- sequence is a SQL comment indicator, which tells the database to ignore everything after it on the same line. This is used to disregard the original password check in the query.