Persistent(Stored) Cross-Site Scripting

What is Persistent(Stored) Cross-Site Scripting?

When any parameter which is stored in the database is vulnerable to XSS, XSS payload is also stored in the database and will be reflected whenever that parameter is displayed on the web page. This is the most severe type of XSS. Here are the example parameters: name, comment, message, about me, etc.

Example:

Suppose an application is having a feature of setting biodata of the user and this biodata is displayed on his public profile. Let's assume, the following code is used to display the biodata of the user.

<p>I am a security analyst.</p>

If XSS prevention is not applied to the biodata parameter, an attacker can exploit it to generate a stored XSS. An Attacker can provide the following payload to the biodata parameter.

<script>exploit_script();</script>

When the above payload is displayed on the web page, the following code would be generated.

<p><script>exploit_script();</script></p>

As we can see malicious code is injected in the source code and it will be executed by the browser.

What is the impact and risk of Persistent XSS?

Persistent XSS is the most severe type of XSS as it is reflected each time when any user visits the page where the payload is displayed. Persistent or stored XSS can affect many users of the application and can cause harm by disclosing their personal information.

The major difference between Persistent and Non-Persistent XSS is Persistent XSS is enabled by the application itself. in Non-Persistent XSS attacker has to find victims by external ways like social engineering. While in Persistent XSS application will work for an attacker and each user of the application who visits the webpage which displays the payload will be infected.

Persistent XSS has a limitation that in most of the cases, the attacker needs to create an account, store the payload and wait for the victim to visit the page. While in Reflected XSS, the attacker can send the link via different social engineering tactics. In one more limitation, an attacker cant cover the tracks as he needs a permanent account till the victim is exploited.

Prevention:

·      Input Validation: Application should validate each input and filter HTML tags and restricted words like "script". Validation must be done at the client-side and the server-side.

·      Encode Output: Application should encode each value to be displayed which is entered by the user. The application should use HTML, URL, Javascript, and CSS encoding.

·      Response Headers: If the web page is not intended to contain any HTML or JavaScript, the application should use the "Content-Type" and "X-Content-Type-Options" headers to make sure that browsers prevent any malicious code execution.

·      Content Security Policy(CSP): A developer should use CSP to reduce the impact of any XSS vulnerabilities.