Exploitation: OWASP Juice Shop Practical Application

Welcome back to Injection Flaws session. In this second part, we will exploit an injection flaw in our intentionally vulnerable application. Before the actual exploitation, I want to introduce you to OWASP Juice Shop, our international vulnerable application. After that, we will practise what we have discussed in the first part and bypass OWASP Juice Shop authentication, exploiting a SQL injection vulnerability. OWASP Juice Shop is yet another OWASP project led by Bjorn Kimminich. It’s an intentionally vulnerable application aimed for application security training. There are several applications like this one, even some of them under the OWASP umbrella. But this is up to date with the latest version of the OWASP Top 10.

This is the OWASP Juice Shop project page, where you’ll find a lot of information about the project and the application itself. After completing this session, come back here and check the available information. For now, let’s focus on the application architecture.

On the left, we have the client, a web application written in JavaScript using the popular Angular framework. Juice Shop supports authentication with Google accounts. Then we have the backend, where there’s an API server running written in Node.JS. The API server interfaces with the file system and the SQL led database, which support SQL for Data Management. If you’re curious about implementation, you can have a look into the source code in the projects repo.

We will come here in the third and last part of this session so that you can see how the vulnerable source code we will exploit next looks like. Without further delay, let’s hack! The login request should be a post request to use access status code, such as 200. Let’s check the details.

Our authentication credentials, email and password, were sent as a JSON object.

Server responded with a JSON object, too, with several tokens and our email.

Let’s see our account profile and then review what happened behind the scene.

The provided authentication data was sent to the backend server where it was merged with the SQL query template and then sent to the database. Here, we can see the SQL query received and executed by the database server. There’s only one row in the table that matches our email and password hash, and this gave us access to our account. Now, let’s hack. First, we need to log out from our regular user accounts. Then we’ll open developer tools, switching to the network tab.

This time, instead of providing a valid email address, we will first check what the server response is if we send a single quote character and a random password.

Notice that, this time, the login post request has a 500 status code, internal server error.

The request data is exactly what we entered in the form.

The response, still in JSON format, this time, is an error object, including the query sent to the database where we can see that our single quote character wasn’t escaped.

This means the application is vulnerable to SQL injection. Let’s improve our payloads and resend the login request with a random password.

In the network tab, we can see that the login request was successful. Let’s check the details.

We can see that what was sent was our payload and an arbitrary password. The server sent a JSON object with some tokens and the admin’s email address. Let’s check our account profile to confirm that we are authenticated as this admin.

So what happened now? In the backend server, we can see how the client provided data was merged into the SQL query template. On the right, the final SQL query sent to the database server. Let’s look at it in detail. There’s no record in the table with an empty email address, but 1 is equal to 1 for every record in the table. The semicolon breaks the SQL statement, and no more conditions are checked until this statement is executed and the results returned back to the backend server. All records will be returned, but since the backend is expecting just one record, only the first one will be considered.

Luckily for the attacker, the considered record is the admin one, meaning that the attacker gets access to the application as administrator. In our next video, we will discuss what makes the application vulnerable and how to prevent it.