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
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
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.
*** This is a Security Bloggers Network syndicated blog from Web Security Blog – Acunetix authored by Tomasz Andrzej Nidecki. Read the original post at: http://feedproxy.google.com/~r/acunetixwebapplicationsecurityblog/~3/oaJx8Xk8GF0/