Persistent Cross-site Scripting (Stored XSS) attacks represent one of three major types of Cross-site Scripting. The other two types of attacks of this kind are Non-Persistent XSS (Reflected XSS) and DOM-based XSS. In general, XSS attacks are based on the victim’s trust in a legitimate but vulnerable web application or website.
A Persistent XSS attack is possible when a website or web application stores user input and later serves it to other users. An application is vulnerable if it does not validate user input before storing content and embedding it into HTML response pages. Attackers use vulnerable web pages to inject malicious code and have it stored on the web server for later use. The payload is automatically served to users who browse web pages and executed in their context. Thus, the victims do not need to click on a malicious link to run the payload (as in the case of Non-Persistent XSS). All they have to do is visit a vulnerable web page.
XSS is the second most prevalent issue in the latest OWASP Top 10 and is found in around two-thirds of all applications. Persistent Cross-site Scripting attacks are less frequent than Non-Persistent ones because the vulnerabilities that make them possible are less common and more difficult to find. On the other hand, Persistent XSS attacks are potentially more devastating than Non-Persistent XSS. The payload is stored so it may infect most of the visitors of the vulnerable web page. Persistent XSS attacks are also referred to as Type 2 XSS attacks because the attack is carried out via two requests: one represents injecting malicious code and storing it on the web server and the other represents victims loading HTML pages that contain the payload.
Description of Persistent XSS
As in the case of most web-based attacks, exploiting Persistent XSS vulnerabilities requires some research. Certain types of websites are more prone to such vulnerabilities because they allow users to share content. Such sites are starting points for such research.
- Forums or message boards
- Blogging websites
- Social networks
- Web-based collaboration tools
- Web-based CRM/ERP systems
- Web-based email server consoles and web-based email clients
- Any sites with visitor comment fields
After an attacker identifies a website as potentially vulnerable, they try to inject script code into data stored on the server. Then, they access the web pages that serve back the payload and check if the script executes. Attackers usually deliver malicious code manually but there are cases when they build tools that inject scripts automatically.
Unlike Non-Persistent XSS, Persistent XSS does not require a social engineering phase. Victims of this attack do not need to be lured into clicking on a crafted link. However, when exploiting Persistent XSS vulnerabilities, attackers often try to get more victims to visit the vulnerable web page so they send spam messages or promote the page on social networks.
Forum XSS Example
After an attacker identifies a forum as vulnerable, they usually start a new topic and insert malicious scripts in the topic title or body. They can also tag the topic using popular keywords so that the topic is a popular search result. The content of the forum post is stored by the server. When victims browse topics or search for certain keywords, they may reach the infected topic. When the topic loads, its content is sent to the victim’s browser and the payload is executed. Alternatively, attackers may build tools that automatically post malicious content in replies to popular/sticky topics, send private messages containing the payload to forum members, etc.
Social Network XSS Example
Social networks allow users to build a profile that contains public information. Attackers can inject malicious JavaScript code into such profile fields. When other social network users visit the malicious profile, the payload is delivered to their web browser and executed.
Consequences
Potential consequences of Persistent XSS attacks are vast. The attack enables execution of arbitrary code in the user’s browser, usually with elevated privileges. For example, most home users still use the default administrator account in Windows. Although the latest Windows operating systems come with user access control and hardened browser policies, they are usually disabled in order to improve the user experience.
Typical goals of Persistent XSS attacks:
- Sensitive cookie theft
- Sensitive data theft
Server-Side Defense
The best way to prevent Persistent XSS is to make sure that you properly sanitize all user input before you store it on the web server. As a second line of defense, sanitize all static content presented to users. Malicious scripts can be encoded and injected in various ways, so source code sanitization parsers should take it into consideration.
You can keep your web applications XSS-free by conducting regular assessment tests using a web vulnerability scanner that detects Cross-site Scripting vulnerabilities and provides you with details on how to fix them.
Client-Side Defense
As a user, you cannot take any actions to prevent a Persistent XSS attack. You could only disable JavaScript in your browser but then most websites would not function properly. The best that you can do is use a secure and up to date browser with XSS filters turned on.
Frequently asked questions
A persistent cross-site scripting (stored XSS) attack is possible when a website or web application stores user input and later serves it to other users. Attackers use vulnerable web pages to inject malicious code and have it stored on the web server for later use. The payload is automatically served to users who browse web pages and executed in their context.
Non-persistent (reflected) XSS is a type of cross-site scripting where the malicious content has to be a part of the request that is sent to the web server. It is then reflected back in such a way that the HTTP response includes the payload from the HTTP request. Attackers use malicious links, phishing emails, and other social engineering techniques to lure the victim into making a request to the server.
If an attacker can abuse an XSS vulnerability on a web page, they can attack the user of that web page and, for example, steal sensitive data such as the user’s session information letting them impersonate that user. Cross-site scripting may also be used to deface a website instead of targeting the user. The attacker can use injected scripts to change the content of the website or even redirect the browser to another web page, for example, one that contains malicious code.
The best way to protect your website from XSS attacks is to eliminate XSS vulnerabilities. To know if you have such vulnerabilities, you need to test your website using a web vulnerability scanner like Acunetix. Acunetix is able to find all types of XSS vulnerabilities, even the rare ones and the ones that are difficult to detect.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
Principal Cybersecurity Writer
