OWASP Juice Shop Level
Updated: Jun 25, 2021
Owasp Juice Shop is a platform I have been considering for quite some time and was very happy to finally get started with a member of my CTF and bug bounty team.
For starters, let me suggest that if you are interested in the Juice Shop, that you set it up using Heroku to seamlessly host the app avoiding the confusion that is apart of all other methods.
Web application vulnerabilities are a large part of any pentest, CTF or bug bounty. Being able to train these skills through repetition in a sanctioned environment is not easy. OWASP Juice Shop however has us covered with their "Very Insecure Web App" known as the "Juice Shop".
The depth and availability that OWASP Juice Shop offers in their intentionally vulnerable web application provides a security training experience that is very unique and largely unmatched without paying big dollars. The Juice Shop is stocked with all types of vulnerabilities for all levels of experience, to guide the beginner or challenge the veteran. Below are the types of vulnerabilities found within the Juice Shop.
sensitive data exposure
XML external entities (XXE)
broken access control
cross-site scripting (XSS)
using components with known vulnerabilities
insufficient logging and monitoring
Finding the score board
The first task of the Juice Shop is to find the score board. In the introduction to the shop, it is suggested we can check the source code, and it is fair to assume that a directory search may also provide us with the score board.
Bonus Payload - Iframe Injection Reflected XSS
This challenge calls for you to inject an iframe in the search box, and provides the specific payload. We are going to take a look at the breakdown of the payload, and an iframe to really grasp whats going on here.
An <iframe> tag calls an inline frame which is used to embed documents or media within the current HTML document. The <iframe> tag is used by the CSS frame work.
Iframe injection is just one of many XSS payloads, to have at your ready when testing a website. In order to defend against iframe injection, it is up to the developer to place unauthorized iframes on a blacklist along with other XSS payloads and illegal characters.
You can test for iframe injection with this basic payload below.
let us take a look at the payload provided by the juice shop for this "Bonus Payload" challenge. The only part of the payload that really matter, is the autoplay, src and url.
autoplay = allow - specifies that our video will auto play
src = https://w.soundcloud.com/player/? - calls the sound cloud web application API
url = Calls the location our particular video is stored in sound cloud
<iframe width="100%" height="166" scrolling="no" frameborder="no" allow="autoplay" src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/771984076&color=%23ff5500&auto_play=true&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true"></iframe>
When we paste this into the search box we get a no results found but the page also loads the iframe playing our video from sound cloud. The song is titled Juice Shop - Jingle, an absolute personal favorite.
Upon further inspection we can see the iframe tag in the html body.
Confidential Document - Sensitive Data Exposure
Access a confidential document.
This challenge is very straight forward. It was easy to over complicate at the start when the final solution was simply navigating to /ftp/. The KISS (Keep it simple rule) really applies here saving me more time than I care to admit.
As we browse through the folder we find several documents including some malware macros. Out of curiosity I downloaded these malware macros. They appear to be octect streams of 6mb. I assume this is for a later challenge, but I opened the malware and it downloaded a file with reference to this link.
Sure enough, this malware is related to the challenges.
Continuing on with the challenge and a little more browsing brings us to the final file "acquisitions".
The DOM stands for document object model and is an application programming interface or API for HTML and XML documents.
A DOM based XSS attack involves executing a payload after modifying the DOM from within the browser on the client side. This is different from XSS stored and reflected attacks, where payloads are found in response pages.
Provoke an error that is neither very gracefully nor consistently handled.
This is a silly challenge that asks us to provoke an error on the website. Simply going through the challenges, or browsing the website will produce enough errors and them some.
Exposed Metrics - Sensitive Data Exposure
Find the endpoint that serves usage data to be scraped by a popular monitoring system.
This question again forced me into over thinking until I tried the obvious of browsing to the endpoint metrics, but only after removing the /# directory in the URL.
Missing Encoding - improper validation
Retrieve the photo of Bjoern's cat in "melee combat-mode".
This challenge involves the modification of a broken image found on the photo wall, with the hopes of restoring it to its normal state. We browse to the photo wall and clearly see a broken image.
Inspecting the code reveals that there are illegal non encoded characters in the image tag, when referencing the source.
The name of the challenge is missing encoding and this is a big hint right here. Our next step is to encode the illegal characters which in this case is the "#" sign. By visiting a url encoder online, we can encode the # sign revealing that the proper encoding sign is %23.
Upon replacing those escape character the image successfully loads.
Outdated Whitelist - Unvalidated Redirects
Let us redirect you to one of our crypto currency addresses which are not promoted any longer.
At first I was not to sure where to go with this, so I started by reviewing the websites main-es2015.js script, where I learned this was the websites primary script. I performed a search for the word bitcoin and found the code block below, where I noticed the specified URL was a redirect. I then copied the address, and appended this to the URL, remembering to remove the /#. This gave us the flag!
Repetitive Registration - Improper Input Validation
Follow the DRY principle while registering a user.
This challenge is interesting but not a security challenge. It is more of a challenge to test/teach you about website code and good practices. The hint is do not repeat yourself with a corresponding hint of user registration. Upon making it to the page, I was not sure what to do so I started to search through the main script "Main_es" and I found a block of code where I was able to see a the design flaw.
The above code is calling the original password form, for the repeatPasswordControl function. This then allows me to pad the actual password with characters after the password. This is a result of the repeatPasswordControl exiting as a function once the string password has been detected to mach itself, none of the characters are read thereafter, becoming accepted and avoiding sanitization.
I was able to use the password apple1pieskyoutdoors and a repeat password value of apple1.
This is a fantastic challenge that will introduce the practice of intercepting communications through the use of Burp Suite.
We fill out the form and submit our feedback, waiting for burp to catch the request. Upon catching the request we can see the HTML has a value of "rating:5" and we simply change this value to 0 and forward our request.
This will then complete the objective but does not provide a live notification for some reason.
The End of Level 1
Keep in mine this only the first level of six within the juice shop. For beginners looking for an introduction to Web application security and CTF's this level reinforces allot of core concepts, along with the coming levels.