SQLi in WHERE clause

Lab: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data

Lab contains a SQLi in the product category filter. When the user selects a category, the application carries out a query like the following: SELECT * FROM products WHERE category = 'Gifts' AND released = 1 To solve: Perform a SQLi that causes the application to display one/more unreleased products

Figure 1 - Screenshot of the lab application

1. By accessing the lab, we see a product page available with different categories and items.

2. Clicking on any of the 'categories' we see the parameter being used in the URL in the lab description and the image below.

3. Analyzing the challenge statement, we're already given the query happening in the backend

   1. We can gather that categories = true and 1 = true

Figure 2 - Screenshot of the lab application showing that category='subject'!

Figure 3 - By changing the value of category, and simply putting a single quote in, we break it

Since we know that category='subject' we can also gather that changing the subject might give us more information

1. Changing the value of category to ' breaks the application and shows an internal server error

2. This denotes the app is most likely vulnerable to a SQLi

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

   2. select all the rows from the products table where the category column is gifts and released is 1

   3. By changing the query /filter?category='-- we ask the application to ignore the column altogether

Figure 4 - By requesting the query to ignore the category, we don't receive an error

1. select * from products where category = '' or 1=1 and released =1

2. Select all the rows from the products table where the category is either equal to nothing or the conditional statement 1=1 will evaluate to true

3. Our payload is then ' or 1=1 --'

Figure 5 - Hooray we did it!