This post will contain screenshots for all of the 1 star challenges of the OWASP Juice Shop which was covered in a previous post. Just as a reminder the Juice Shop web application relies upon HTML5 web storage to store a cookie with current progress. If you attempt to access the Juice Shop from a different host machine or different browser you might not have your progress saved. However, if you were to restart the host machine or restart the remote server hosting the application your stored cookie will refresh your progress.
The first real (albeit easier challenge) is really to find the scoreboard, because once found the scoreboard will help us keep track of what is expected to be exploited. So the first step of any web application penetration test is to really understand how the code works, and look for clues to the underlying platform the application runs on. Looking through the source code of the navigational bar at the top of the page it is noted that there is a link
<a href='#/score-board'> So once we browse to that link the scoreboard will be visible from future
Using the same logic as with the score-board above we can guess what the administration page might be. Navigate to
\#\administration to achieve the next challenge.
During the assessment you want to "walk the happy path" which is just an analogy for using the web application how it is meant to be used. If you are focused on breaking the application from the beginning you might miss sections that are hidden from your tools or processes. For example, in the next challenge using the application as intended by selecting items in your cart and checking out will net an additional directory that was not visible through other links.
/ftp/ directory contains multiple files which may or may not have been left unintentionally. By choosing one such as the
acquisitions.md file we can complete the third challenge which is to access a confidential document.
The next challenge is almost a freebie. Using the application in a normal way, or by scanning/spidering the site will provoke an error message that is not handled gracefully. If you have not achieved this challenge at this point wait, and come back to it after all the 1 star challenges are completed.
The next challenge is to be redirected to a donation site that is no longer in business. There are several ways to find this depending on your tools. You could use BurpSuite's Professional Engagement tool to extract all comments from the source code to locate the out of donation page. Or you could use some common intuition to suspect where the link might be. By going into your basket section and clicking the payment button you will see a list of supported payment options. One thing to keep an eye on is that lazy developers might just comment out code. However, that means the code will still be delivered to the client-side.
By looking through the source code of the supported payment options we see there is a commented out section for a
gratipay.com We can uncomment this code by editing the HTML in Firefox's developer tools. Having trouble editing the single line? Firefox makes you edit as blocks unlock the Chrome browser. Thus, if you go above to the
div above and edit the block it will allow you to uncomment the single line ( That took me entirely too long to figure out).
Once you uncomment the line and exit the block the button for Gratipay will show up, and simply clicking the link will redirect you to the Gratipay website. Uh oh. 404? Well yeah, it's out of business, but if you return to Juice Shop you should get a success message.
Alright, let us talk about Cross-Site Scripting or more commonly known as XSS now. XSS attacks are a type of injection, in which malicious script are injected into otherwise benign and trusted websites. There are some distinctions between different methods of XSS attacks. The two that we are going to focus on currently is DOM based and Reflected.
Reflected is the XSS attack when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself. The attack string is included as part of the crafted URI (Uniform Resource Identifier).
So for Juice Shop we need to find a location where we can inject code into a DOM and also into a URI. Remember our "happy path" we went down earlier? Did you note when using the tracking it adds your
id in the URL? You can see how searching for order number 1234 in the screenshot below adds
For the DOM XSS we need to find a spot where the user would manually type something in. At the top of every page there is a simple search feature. By injecting an alert into the search feature and pressing search will execute a DOM based XSS.
This leaves us with only one challenge left from the 1 star category. Leaving a scathing zero star review. So under the Contact Us section you can see that there is a rating system of 1-5 stars. The first attemp will be to try and submit a review without selecting any of the stars, but you will find that you cannot force the submission. So for the first time of Juice Shop it is time to break out BurpSuite.
So select 1 star and make sure BurpSuite is set to capture the request as it goes through. You want to make sure intercept is on to begin with.
This is what the request will look like when you capture the submission of the form. As you can see at the bottom there are several parameters that are being passed to the server side. Luckily, BurpSuite will let us modify these before sending them on to the server side.
By changing the rating from 1 to 0 and then forwarding the request we have successfully submitted a scathing zero star review to the application.
This brings us to the end of Part 1 of Juice Shop. Through the course of this post we have completed all of the 1 star challenges. Keep your eyes out for the second part.