Skip to content

Lab 06 Injection

Jump to bottom
Tomas Rosenqvist edited this page Jun 13, 2019 · 17 revisions

Injection

Challenge "Login Admin"

In Lab 1, we noticed that the username/password verification subsystem appears to be vulnerable to SQL injection (judging by the error message). Let's take a closer look at the error message.

Inspect the error message to gain insights into how the login function is implemented

  1. Go to the login form.
  2. Enter 'changeme (including the apostrophe ') as the email and secret as the password.
  3. Login.
  4. Inspect the error message.

Questions

  • Can you see how/where your input values ('changeme and secret) were used?
  • Why do you think these particular input values caused an error?

Circumvent the login logic using a simple SQL injection

The error message strongly suggests that the login function is susceptible to SQL injection attacks. Specifically, it looks like we might be able to short-circuit the logic that checks for the correct username/password combination, by entering SQL fragments in the email input field.

  1. Go to the login form.
  2. Enter ' or 1=1;-- as the email and any password.
  3. Login.
  4. Check if the system treats you as a logged in user, e.g. by adding items to the basket.

Questions

  • Which user do you think you are logged in as?
  • What happened on the back-end during this scenario?
    • What do you think the SQL code looked like that got executed?
    • Why did you end up as this particular user?

Challenge "Login Jim"

In this lab, we're going to try logging in as a specific user (Jim). First, you need to get Jims user name. Fortunately, the Juice Shop lists all registered users in the administration view. For a different application, you could try finding Jim on LinkedIn and then guessing Jims email address based on his current employer. You could also use some sort of social engineering to get hold of his user name.

For this lab, we're going to use the administration view though.

Find Jims email address

  1. Login as any user. Create a new user if you need to.
  2. Go to the administration view. Note Jims email address there.
  3. Log out.

Perform a SQL injection attack to login specifically as Jim

  1. Go to the login form.
  2. Enter Jims email address followed by ';-- in the email field and any string in the password field.
  3. Check if the system treats you as a logged in user, e.g. by going to the administration view.

Questions

  • What do you think the SQL code looked like that got executed?
    • What is the major difference between this scenario and the previous?

Challenge "Order the Christmas special offer of 2014"

The Juice Shop might contain certain products that are not offered for sale (e.g. because they're out of stock or are not yet up for sale). Since they're not available, these products probably won't show up in search results etc. since that would just frustrate the customer. Let's see if we can find (and order) such a product anyway.

We don't know how the products listing is implemented, but a naive guess is that when searching for widget, the system will execute a SQL query similar to SELECT * FROM Product WHERE Name LIKE '%widget%' AND IsAvailable = 1. If that is the case, then we could short-circuit the IsAvailable check by injecting a SQL comment. Comments in many SQL dialects are indicated by -- or enclosed in /* */. Following our naive guess, we'd want to execute the SQL query SELECT * FROM Product WHERE Name LIKE '%widget%';-- AND IsAvailable = 1, causing IsAvailable = 1 to be treated as a comment and thus excluding it from the actual evaluation.

Attempt to list all products by injecting a SQL comment

  1. Login as any user. Create a new user if you need to.
  2. Open the network tab of your developer tools in your browser.
  3. Search for ';-- in the Juice Shop product search bar.
  4. Notice that the developer tools shows a failed request (i.e. a request shown in red and with the status code 500).
  5. Click the request in the developer tools to inspect it.

Depending on which browser/version you're using, you might need to expand the response to view all of it.

  1. Notice how the response contains the SQL statement being used (and where your search input was inserted).

Attempt to list all products by injecting a short-circuiting filter

Now that you know how the resulting SQL statment looks, you can more easily create an injection fragment to short-circuit the DeletedAt filter.

  1. Use the information from the previous section to craft a new search string that short-circuits the DeletedAt filter in the SQL.

Hint

  1. Add the "Christmas Super-Surprise-Box (2014 Edition)" to your basket.
  2. Checkout.

Questions

  • What is the risk to the Juice Shop during this scenario?
  • What is the risk to a general Web app for this type of scenario?

Recommended reading

Clone this wiki locally