In this article I would like to briefly introduce the OWASP Juice Shop - a great way to educate about common security vulnerabilities in applications - for both inexperienced and experienced developers. It can also be found on Github.

What is the OWASP Juice Shop?

The Juice Shop is a sample application that has deliberately implemented every conceivable security vulnerability. There is also a scoreboard (which you first have to find by exploiting a vulnerability), which gives us a few tips on which vulnerabilities can be exploited. This makes the Juice Shop the ideal training tool for raising awareness of security vulnerabilities by showing how they can be exploited. This immediately creates an understanding of why a security gap should be avoided.

That sounds good! How can I get started?

An easy way to work with the Juice Shop is to set it up locally. This can be started in a Docker container, for example, for which there is an official image. Once Docker has been installed, the following can be used for a quick test

run --rm -p 3334:3000 bkimminich/juice-shop

Or if we want the container to remain intact:

docker run -d --restart=always -p 3334:3000 --name juiceshop bkimminich/juice-shop

I am using the port `3334` in the example, but of course any other port can be used. If we now call up


, we find this beautiful web store:

And what do I do next?

The first challenge

The first thing we had to do was find the scoreboard. Unfortunately, this was supposedly safely hidden. In any case, we can't find any reference to the scoreboard anywhere, not even in the navigation menu:

Let's take a look at the sources from the page. Obviously, this is a single-page application. Let's search for 'score' and lo and behold:

For the scoreboard, we must therefore visit '/score-board':

What do we learn from this?

  • With a single-page application in particular, data that is actually secret can sometimes be hidden in the sources. Care should be taken to conceal this information
  • Just because a page is not directly linked does not mean that it cannot be guessed. There should always be an additional safeguard

Next try

We hope that the site is also susceptible to SQL injection. Maybe we can log in as administrator. To do this, we go to the login page and simply enter `'` in the username field and any password:

And lo and behold, not only do we get an unhandled error, but to make matters worse, we even see the SQL query that was executed under our requests in the browser's dev tools! Then we change our user name to

' OR email LIKE '%admin%';--

and see what happens. The password field gets any characters - we don't need a password, the field just needs to be filled in. Lo and behold, we are logged in:

What do we learn from this?

  • SQL injection should be avoided at all costs
  • SQL queries should not be transferred to the frontend

What comes next?

There are still a lot of exciting challenges that are designed to teach us about typical security vulnerabilities. Over time, they become more and more difficult and you can spend hours on them (or find the solutions on the internet, but where would be the fun in that?). If you have a good picture of how vulnerabilities are exploited, you can also gain a better understanding of how and why to avoid them. And that's exactly what the Juice Shop is a great way to do and I can recommend everyone to give it a try! I can also highly recommend the Burp Suite for some challenges. This is also used by real hackers to hack our applications.

I hope that I have been able to provide at least a little bit more security in the world of software development. And in this context, a big thank you to everyone who contributed to the Juice Shop!


No Comments

Write comment

* These fields are required

Related Posts