Stored Cross-site Scripting vulnerability occurs when the data provided by the attacker is saved on the server, and then publicly displayed on regular pages without proper HTML escaping.
In normal XSS attacks, an attacker needs to reach the target user, but in a stored XSS, an attacker can simply inject the payload and wait for users to visit the affected page. As soon as someone visits the page, the attacker's stored payload will get executed.
XSS targets the users instead of the server of the application. Although this is a limitation, since it only allows attackers to hijack other users' sessions, the attacker might attack an administrator to gain full control over the application.
Stored cross-site scripting is more dangerous than other types for a number of reasons:
- The payload is not visible for the browser's XSS filter.
- No need for direct user interactions like in a reflected XSS scenario. Instead, ordinary users may trigger the exploit during normal use of the application.
- Users might accidentally trigger the payload if they visit the affected page, while a crafted URL or specific form inputs would be required for exploiting reflected XSS.
- XSS can enable client-side worms, which could modify, delete or steal other users' data within the application.
- The website may redirect users to a new location, can be defaced or used as a phishing site.
- Sensitive information such as cookies can be stolen
A stored XSS vulnerability can happen if the username of an online forum member is not properly sanitized when it is printed on the page. In such case an attacker can insert malicious code when registering a new user on the form. When the username is reflected on the forum page, it will look like this:
Registered since: 2016
The above code is triggered every time a user visits this forum section, and it sends the users' cookies of the forum to the attacker, who is then able to use them to hijack their sessions. Stored XSS can be a very dangerous vulnerability since it can have the effect of a worm, especially when exploited on popular pages.
For example imagine a forum or social media website that has a public facing page that is vulnerable to a stored XSS vulnerability, such as the profile page of the user. If the attacker is able to place a malicious payload that adds itself to the profile page, each time someone opens it the payload will spread itself with an exponential growth.
In other cases, like in an href or src attribute it makes sense to use URL encoding (%3C%22%27) in order to prevent XSS and an attacker from adding additional parameters.
Additionally, you should implement a strong Content Security Policy (CSP) as a defence-in-depth measure if an XSS vulnerability is mistakenly introduced. Due to the complexity of XSS-Prevention and the lack of secure standard behavior in programming languages and frameworks, XSS vulnerabilities are still common in web applications.
CSP will act as a safeguard that can prevent an attacker from successfully exploiting Cross Site Scripting vulnerabilities in your website and is advised in any kind of application. Please make sure to scan your application again with Content Security Policy checks enabled after implementing CSP, in order to avoid common mistakes that can impact the effectiveness of your policy. There are a few pitfalls that can render your CSP policy useless and we highly recommend reading the resources linked in the reference section before you start to implement one.