Lab 07 Cross Site Scripting

Preparations

1. Make sure you're browsing the Juice Shop via HTTPS.

Using HTTPS is not strictly necessary, but prevents any intermediary firewall from detecting XSS attempts if you're running from a company network or similar.

Challenge XSS Tier 0

Inject javascript into the order tracking form

2. Open Devtools in your browser (and keep it open during this lab).
3. Log in as any user.
4. Use the order tracking form to inject javascript code
   • Go to the order tracking form.
   • Enter <script>alert("XSS")</script>.
   • Use Devtools to inspect the server response.
5. Notice how the code you injected is included in the server response (i.e. it is reflected back to the client).

Challenge XSS Tier 1

Inject javascript into the product search bar

1. In the product search bar, enter <h1>huge text</h1> and hit search.
2. Notice how the text you entered appears in the search results page, and that it seems to be formatted as a heading (i.e. quite large text). Also notice what the current URL is in the address field of your browser.
3. Now search for <script>alert("XSS")</script> in the product search bar.
4. Use Devtools to inspect the server response.

Inject javascript into the URL

Showing annoying popups to yourself might seem pointless, but can it be used to annoy someone else as well?

1. Copy the URL from the address field in your web browser
2. Open a new incognito browser tab (Chrome) or InPrivate tab (Edge/IE)
3. Paste the url in the new tab (i.e. imagine that this browser window belongs to a different user who was sent this URL in an e-mail by the attacker).

Questions

• What's the difference between the two challenges (Tier 0 and Tier 1)?

Challenge XSS Tier 2

Create a new user, and inspect the requests that are made in the application

1. Go to the new user registration form.
2. Open Devtools.
3. Create a new user, using valid values for e-mail, password etc.
4. Inspect the request in devtools.

Create a new user and attempt to inject javascript in the e-mail address field

5. Create a new user just like before, but enter <script>alert("XSS")</script> as the e-mail address.
6. Use Devtools to enable the submit button and create the user.
7. Inspect the request in devtools. Do you notice anything missing from it? Why might it be missing?

Create a new account using Postman instead of your browser

8. Start Postman (you don't need to register for an account).
9. Create a new Request, and save it in a new Collection.
10. Set the request type to POST.
11. Set the body to raw and change the type from Text to JSON (application/json).
12. Copy the URL from the request in devtools and paste it into Postman.
13. Expand the Request Payload for the request in devtools, and copy it (a JSON object) into the Postman body.

You might need to click "view source" in order to copy the JSON object including curly brackets.

14. Alter the payload in Postman and add "email": "<script>alert(\"XSS\")</script>".
15. Submit the request using Postman.

Login as a different user (i.e. the victim) to see if the attack succeeded

16. Go back to your browser.
17. Login as any user.
18. Go to the administration view.
19. After closing the popup, do you notice anything unusual in the user table?

Questions

• What do you think happened when you used the browser to create a user? Why didn't it work as expected?

Suggested reading

• OWASP Top 10-2017:A7 Cross-Site Scripting (XSS)
• XSS on the OWASP wiki