WebSec 101: JuiceShop ⭐ challenges


Welcome to the continuation of my web sec journey through Juice Shop!

Today I would like to focus on several challenges worth one star (⭐). We will not miss XSS,  Sensitive Data Exposure, Security Misconfiguration, Improper Input Validation, Unvalidated Redirects, and others!

The previous post was devoted to setting up the environment, and we’ve finished with discovering the scoreboard:

⭐ Score Board in Juice Shop

All of the tasks are categorized:

  • by difficulty – 6 difficulty levels, represented by number of stars: from ⭐ to ⭐⭐⭐⭐⭐⭐
  • And by categories – 15 of them:
    • Broken Access Control
    • Broken Anti-Automation
    • Broken Authentication
    • Cross Site Scripting (XSS)
    • Cryptographic Issues
    • Improper Input Validation
    • Injection
    • Insecure Deserialization
    • Miscellaneous
    • Security Misconfiguration
    • Security through Obscurity
    • Sensitive Data Exposure
    • Unvalidated Redirects
    • Vulnerable Components
    • XML External Entities (XXE)

I would like to learn and test the environment with increasing difficulty, so I will stick to ⭐ challenges today.

As you can see, some of them are provided with hacking tutorials:

Hacking tutorial icon

And all of them have hints:

Solved/unsolved and hints button

As I described in the previous article, it’s strongly recommended to use the “Happy Path first.”

Now, let’s jump on to solving all of them.

Score Board (Miscellaneous)

Finding the scoreboard is one of Pwning The Juice Shop Manual tiles, full of hints, tips, and tricks.

There are two ways of solving this one, and they are explicit said:
“Look through the client-side JavaScript in the Sources tab for clues. Or just start URL guessing. It’s up to you.”

Guessing is always an option, but… let’s try to find those client-side JS files. Browser Dev Tools shows that they are 5 of them:

Juice Shop JavaSciprt files

I’ve opened main-es2015.js in Chrome Dev Tools, and after a quick CTRL+F answer shows up:

            path: "score-board",
            component: Oo

To be honest, anybody would probably guess it. But the beginning is the time to get familiar with browser tools.

After completing that task, the scoreboard is now shown in the context menu:

Now we have quick access to the Score Board

Privacy Policy (Miscellaneous)

This one is even easier. While walking the happy path, I was encouraged to create an account, so I did. (remember to always provide FAKE DATA to the vulnerable app!)

After signing up, the Privacy policy is available from the account context menu:

Privacy Policy

DOM XSS & Bonus Payload (XSS)

In this one, we are encouraged to perform DOM XSS attack with:

<iframe src="javascript:alert(`xss`)">

DOM Based XSS is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.


So we need to find a place where the user input is contained in the page (e.g., via search bar):

The search result may be a scent to pick up

So let’s check on that trail:

DOM XSS performed 🙂

And it works!

After that, to finish XSS ⭐ challenges, I went for Bonus Payload.

The description is simple:  Use the bonus payload (…) in the DOM XSS challenge.

Easy peasy, right? But I wanted to check the tutorial, and it was pretty straightforward!

Step one of the tutorial – and hew as right
346Confirming that our guess about the Search field was correct
And the most important one 🙂

After that, I listened to a very nice OWASP Juice Shop Jingle, which finished the task!

I do recommend listening!

⭐Error Handling (Security Misconfiguration)

One and only security misconfiguration error is described as Provoke, an error that is neither very gracefully nor consistently handled. And hinted with: Try to submit wrong input to forms. Alternatively, tamper with URL path or parameters.

For the time being, I would like to keep it simple, so I would try to play with forms. The search form was already used for two XSSes, so I better use the login form.

Typical errors related to logins forms are related to apostrophes. So after first, best guess:

Error not properly handled

Confidential Document (Sensitive Data Exposure)

In this one, we need to access a confidential document.

It got me thinking what kind of document would be confidential ‘enough.’ Probably invoice would do the job (Note: it didn’t). So I ordered some products, and while my order was in transit, I wanted to get my order confirmation:

Printing fake order confirmation

The link to the file that caught my eye:


So I decided to shorten it a little bit:


This leads us to the exciting directory:

FTP directory

And there is one confidential document:

# Planned Acquisitions

 > This document is confidential! Do not distribute!

Completed 😉

Exposed Metric (Sensitive Data Exposure) 

In this one, we need to Find the endpoint that serves usage data to be scraped by a popular monitoring system.

One of the most popular event monitoring and alerting open-source software for this purpose is Prometheus. As we can read in the Prometheus First steps document (https://prometheus.io/docs/introduction/first_steps/), metrics are available with the/metrics link.

So when we check:


Our task is completed 😉

⭐Outdated Whitelist (Unvalidated Redirects)

We need to that of the cryptocurrency addresses that are no longer promoted.

This one is unclear, leading decided to visit more hints which led me to Pwning the Juice Shop.

I found out that “Some time ago, the Juice Shop project accepted donations via Bitcoin, Dash, and Ether. It never received any, so these were dropped at some point.” And then, after (again) searching js files, it was easy to find that there is some not cleaned redirection to Bitcoin wallet.

Also, there was one more important hint:
It is, of course, not sufficient to just visit any of the cryptocurrency links directly to solve the challenge.

Directly is a crucial word 😉 the JS code looks like this:

showBitcoinQrCode() {
                    this.dialog.open(bn, {
                        data: {
                            data: "bitcoin:1AbKfgvw9psQ41NbLi8kufDQTezwG8DRZm",
                            url: "./redirect?to=https://blockchain.info/address/1AbKfgvw9psQ41NbLi8kufDQTezwG8DRZm",
                            address: "1AbKfgvw9psQ41NbLi8kufDQTezwG8DRZm",
                            title: "TITLE_BITCOIN_ADDRESS"

And the proper link to visit looks like this:

http://xxx:3000/#/ redirect?to=https:// 

Missing Encoding (Improper Input Validation)

Now we have to retrieve the photo of Bjoern’s cat in “melee combat-mode.” So the first place where I will try to look for pictures would be Photo Wall.

And actually, there is some photo that doesn’t display correctly:

Photo with error

While inspecting HTML, we can see that the file source contains emoji and hashes :

<img _ngcontent-cnn-c217="" 
class="image" src="assets/public/images/uploads/
alt="😼 #zatschi #whoneedsfourlegs">

After applying missed encoding (%F0%9F%98%BC for 😼 and %23 for #) and replacing incorrect src with:


We can see Bjoern’s cat 🙂

Bjoern’s cat in “melee combat-mode.”

Repetitive Registration (Improper Input Validation)

I need to follow the DRY principle while registering a user for this task.

What is the DRY principle? As we can read in the Pwning the Juice Shop manual:

The DRY (Don’t Repeat Yourself) Principle states:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Pwning the Juice Shop

There is also mentioned user registration form with the repeat password field. For me, this is the signal to start Burp.

Note: there might be an issue with using Burp while inspecting the localhost app. Description of how to solve it is in the conclusion of this article.

After filling the registration form with repeated passwords:

Filled registration form

Burp intercepts request with JSON:

{"id":2,"question":"Mother's maiden name?",

After changing the password repeat, we have completed the task 😊

Zero Stars (Improper Input Validation)

In this one, we have to “Give devastating zero-star feedback to the store.” Which should be easy as pie with Burp.

There are dedicated Customer Feedback bookmark, so I need to fill out the form:

Filling Customer Feedback form

And my request looks like this:

"comment":"0star! (***.com)",

Changing rating to 0 leads me to success 😊


After these quick Exerc, is my scoreboard looks as it should:

Score Board all green

After this quick warmup, I’m ready for another round with ⭐⭐ challenges!

Note about Burp: While I was doing these challenges, partially on my desktop, it occurred that Burp may not intercept properly requests going for localhost.

To work around this issue, you need to:

  • Chrome – configure Windows proxy to listen on loopback:
Adding <-loopback> entry
  • Firefox – change  network.proxy.allow_hijacking_localhost to True

That’s it for today, and thank you for reading my walkthrough for ⭐ challenges.  


Reference list:

  1. DOM based XSS – OWASP
  2. Pwning OWASP Juice Shop
  3. Prometheus – First steps
  4. OWASP Juice Shop Jingle

Check out related posts:

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

%d bloggers like this: