Cross Site Scripting (XSS)
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.1
Challenges covered in this chapter
|API-only XSS||Perform a persisted XSS attack with
|Classic Stored XSS||Perform an XSS attack with
|Client-side XSS Protection||Perform a persisted XSS attack with
|DOM XSS||Perform a DOM XSS attack with
|HTTP-Header XSS||Perform a persisted XSS attack with
|Reflected XSS||Perform a reflected XSS attack with
|Server-side XSS Protection||Perform a persisted XSS attack with
|Video XSS||Embed an XSS payload
Perform a persisted XSS attack without using the frontend application at all
As presented in the
Architecture Overview, the OWASP Juice
side. Even without giving this fact away in the introduction chapter,
you would have quickly figured this out looking at their interaction
happening on the network. Most actions on the UI result in
XHR) objects being sent and responded to by the
For the XSS Tier 3 challenge it is necessary to work with the
server-side API directly. You will need a command line tool like
tool for HTTP request tampering
to master this challenge.
- A matrix of known data entities and their supported HTTP verbs through the API can help you here
- Careless developers might have exposed API methods that the client does not even need
Perform an XSS attack on a legacy page within the application
In the Architecture overview you were told that the Juice Shop uses a modern Single Page Application frontend. That was not entirely true.
- Find a screen in the application that looks subtly odd and dated compared with all other screens
- What is even better than homegrown validation based on a RegEx? Homegrown sanitization based on a RegEx!
Perform a persisted XSS attack bypassing a client-side security mechanism
This challenge is founded on a very common security flaw of web applications, where the developers ignored the following golden rule of input validation:
- There are only some input fields in the Juice Shop forms that validate their input.
- Even less of these fields are persisted in a way where their content is shown on another screen.
- Bypassing client-side security can typically be done by
- either disabling it on the client (i.e. in the browser by manipulating the DOM tree)
- or by ignoring it completely and interacting with the backend instead.
Perform a DOM XSS attack
- This challenge is almost indistinguishable from Perform a reflected XSS attack if you do not look "under the hood" to find out what the application actually does with the user input
Perform a persisted XSS attack through an HTTP header
This XSS challenge originates from an unsafely processed user input via an HTTP header. The difficulty lies in finding the attack path whereas the actual exploit is rather business as usual.
- Finding a piece of information displayed in the UI that could originate from an HTTP header
- You might have to look into less common or even proprietary HTTP headers to find the leverage point
- Adding insult to injury, the HTTP header you need will never be sent by the application on its own
Perform a reflected XSS attack
Reflected Cross-site Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page. The attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim.2
- Look for an input field where its content appears in the response when its form is submitted.
- Try probing for XSS vulnerabilities by submitting text wrapped in an
HTML tag which is easy to spot on screen, e.g.
Perform a persisted XSS attack bypassing a server-side security mechanism
When you actually understand a security mechanism you have a lot higher chance to beat or trick it somehow, than by using a trial and error approach.
- The Comment field in the Contact Us screen is where you want to put your focus on
- The attack payload
- Look for possible dependencies related to input processing in the
package.json.bakyou harvested earlier
- If an
xssalert shows up but the challenge does not appear as solved on the Score Board, you might not have managed to put the exact attack string
Embed an XSS payload into our promo video
As with the previous one, the difficulty of this challenge is based on how hard it is to successfully place the XSS payload in the application.
- Without utilizing the vulnerability behind another ⭐⭐⭐⭐⭐⭐ challenge it is not possible to plant the XSS payload for this challenge
- The mentioned "marketing collateral" might have been publicly advertised by the Juice Shop but is not necessarily part of its sitemap yet
- This challenge will always partially keep you blindfolded, no matter how hard you do research and analysis.