Cross-site Scripting (XSS) is a prevalent security vulnerability in web applications that allows attackers to inject malicious scripts into web pages viewed by users. In this blog post, we will explore the concept of reflected XSS, compare it with stored and DOM XSS, and discuss if reflected XSS can also be stored or DOM XSS.
Reflected XSS occurs when a web application includes unsanitized user input in its response. The attacker crafts a URL containing the malicious script and sends it to the victim. When the victim clicks on the link, the web application reflects the script back to the user’s browser, where it is executed. Since the script is not stored on the server, the attack relies on social engineering to trick users into clicking the malicious link.
An example of a reflected XSS payload could be:
https://example.com/page?item=”><script>alert(1)</script>
But don’t stop there! You can also have reflected XSS in POST request bodies. Though that seems to be found less often.
Stored XSS, also known as persistent XSS, differs from reflected XSS in that the malicious script is saved on the server. The attacker submits the malicious payload through a form, comment, or any input field that is stored in the web application’s database. When users access the affected page, their browsers execute the stored script.
Key differences between reflected and stored XSS include:
Check out this link to see a stored XSS that Brackish Security found during a penetration test.
DOM XSS is a type of XSS vulnerability that occurs when a web application processes user input insecurely in the client-side JavaScript code. The attack takes place in the browser’s Document Object Model (DOM) when a user input is handled unsafely by the JavaScript code. Unlike reflected and stored XSS, DOM XSS does not rely on server-side processing of the payload.
Key differences between reflected and DOM XSS include:
In some cases, a reflected XSS vulnerability can also be a DOM XSS vulnerability. This occurs when the web application uses client-side JavaScript to process user input and manipulate the DOM without proper sanitization. In this scenario, the payload is part of the URL (as in reflected XSS) but is executed in the DOM, combining both attack types.
However, it is essential to note that reflected XSS is generally not also a stored XSS, as these are distinct attack types with different mechanisms. Reflected XSS relies on user interaction and is not stored on the server, while stored XSS is saved on the server and does not require user interaction to execute the malicious script.
With that said, there are cases where an application will take input in a mutable action from the URL, in these cases the user supplied input may be stored in the database and rendered later, which would be a stored XSS. Or, in some cases, the user input could get logged somewhere and rendered in a different application – maybe an admin panel – which would be a stored and blind XSS opportunity.
As you can see, an XSS can often be classified in multiple categories.
Understanding the differences between reflected, stored, and DOM XSS is crucial in developing secure web applications and also in testing for vulnerabilities. XSS can often be chained together with other vulnerabilities such as CSRF to achieve account takeovers or even remote code execution. And as you can see, sometimes an XSS vulnerability just doesn’t fall into one category.
Developers should employ proper input validation, output encoding, and secure coding practices to protect web applications from XSS vulnerabilities. There are many libraries and packages out there than can sanitize user input – it’s best to not roll your own solution. For example the DOMPurify package is a highly used in this manner.
Check out the following links to learn more about XSS:
And check out these links to see some real life XSS discoveries:
https://hackerone.com/reports/438240
https://hackerone.com/reports/1818163