Skip main navigation

New offer! Get 30% off your first 2 months of Unlimited Monthly. Start your subscription for just £35.99 £24.99. New subscribers only T&Cs apply

Find out more

Exploitation: OWASP Juice Shop Practical Application

This video demonstrates how to use the OWASP Juice Shop to demonstrate how a hacker may try to access an 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.

This video demonstrates how to use the OWASP Juice Shop to demonstrate how a hacker may try to access an application.

Throughout this course, you will use OWASP Juice Shop to practically apply what you are learning. In this video, you will have an initial demonstration of how the OWASP Juice Shop works so that you can familiarize yourself with the platform.

Reflect and share: Were you able to follow along and replicate what you saw in the video? Share your questions and comments here, and try to help others who have queries.

This article is from the free online

Advanced Cyber Security Training: OWASP Top 10 and Web Application Fundamentals

Created by
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now