CAPEC-592: Stored XSS
An adversary utilizes a form of Cross-site Scripting (XSS) where a malicious script is persistently "stored" within the data storage of a vulnerable web application as valid input.
Last updated
Overview
Initially presented by an adversary to the vulnerable web application, the malicious script is incorrectly considered valid input and is not properly encoded by the web application. A victim is then convinced to use the web application in a way that creates a response that includes the malicious script. This response is subsequently sent to the victim and the malicious script is executed by the victim's browser. To launch a successful Stored XSS attack, an adversary looks for places where stored input data is used in the generation of a response. This often involves elements that are not expected to host scripts such as image tags ( ), or the addition of event attributes such as onload and onmouseover. These elements are often not subject to the same input validation, output encoding, and other content filtering and checking routines.
How the attack works
The phases an attacker typically follows to carry out this attack.
- Step 1Explore
[Survey the application for stored user-controllable inputs] Using a browser or an automated tool, an adversary follows all public links and actions on a web site. They record all the links, the forms, the resources accessed and all other potential entry-points for the web application. The adversary is looking for areas where user input is stored, such as user profiles, shopping carts, file managers, forums, blogs, and logs.
- Use a spidering tool to follow and record all links and analyze the web pages to find entry points.
- Use a proxy tool to record all links visited during a manual traversal of the web application.
- Use a browser to manually explore the website and analyze how it is constructed. Many browsers' plugins are available to facilitate the analysis or automate the discovery.
- Step 2Experiment
[Probe identified potential entry points for stored XSS vulnerability] The adversary uses the entry points gathered in the "Explore" phase as a target list and injects various common script payloads and special characters to determine if an entry point actually represents a vulnerability and to characterize the extent to which the vulnerability can be exploited.
- Use a list of XSS probe strings to submit script in input fields that could be stored by the web application. If possible, the probe strings contain a unique identifier so they can be queried for after submitting to see if they are stored.
- Use a list of HTML special characters to submit in input fields that could be stored by the web application and check if they were properly encoded, replaced, or filtered out.
- Step 3Experiment
[Store malicious XSS content] Once the adversary has determined which stored locations are vulnerable to XSS, they will interact with the web application to store the malicious content. The adversary can have many goals, from stealing session IDs, cookies, credentials, and page content from a victim.
- Store a malicious script on a page that will execute when viewed by the victim.
- Use a tool such as BeEF to store a hook into the web application. This will alert the adversary when the victim has accessed the content and will give the adversary control over the victim's browser, allowing them access to cookies, user screenshot, user clipboard, and more complex XSS attacks.
- Step 4Exploit
[Get victim to view stored content] In order for the attack to be successful, the victim needs to view the stored malicious content on the webpage.
- Send a phishing email to the victim containing a URL that will direct them to the malicious stored content.
- Simply wait for a victim to view the content. This is viable in situations where content is posted to a popular public forum.
What the attacker needs
Prerequisites
- An application that leverages a client-side web browser with scripting enabled.
- An application that fails to adequately sanitize or encode untrusted input.
- An application that stores information provided by the user in data storage of some kind.
Skills required
- Medium skill: Requires the ability to write scripts of varying complexity and to inject them through user controlled fields within the application.
Resources required
- None: No specialized resources are required to execute this type of attack.
Consequences
What a successful CAPEC-592 attack can achieve.
Read Data
Affects: Confidentiality
A successful Stored XSS attack can enable an adversary to exfiltrate sensitive information from the application.
Gain Privileges
Affects: Confidentiality, Authorization, Access Control
A successful Stored XSS attack can enable an adversary to elevate their privilege level and access functionality they should not otherwise be allowed to access.
Execute Unauthorized Commands
Affects: Confidentiality, Integrity, Availability
A successful Stored XSS attack can enable an adversary run arbitrary code of their choosing, thus enabling a complete compromise of the application.
Modify Data
Affects: Integrity
A successful Stored XSS attack can allow an adversary to tamper with application data.
How to mitigate it
Defenses that reduce the risk of CAPEC-592.
- Use browser technologies that do not allow client-side scripting.
- Utilize strict type, character, and encoding enforcement.
- Ensure that all user-supplied input is validated before being stored.
Examples
An adversary determines that a system uses a web based interface for administration. The adversary creates a new user record and supplies a malicious script in the user name field. The user name field is not validated by the system and a new log entry is created detailing the creation of the new user. Later, an administrator reviews the log in the administrative console. When the administrator comes across the new user entry, the browser sees a script and executes it, stealing the administrator's authentication cookie and forwarding it to the adversary. An adversary then uses the received authentication cookie to log in to the system as an administrator, provided that the administrator console can be accessed remotely.
An online discussion forum allows its members to post HTML-enabled messages, which can also include image tags. An adversary embeds JavaScript in the image tags of their message. The adversary then sends the victim an email advertising free goods and provides a link to the form for how to collect. When the victim visits the forum and reads the message, the malicious script is executed within the victim's browser.
Frequently asked questions
Common questions about CAPEC-592.
- What is CAPEC-592?
- An adversary utilizes a form of Cross-site Scripting (XSS) where a malicious script is persistently "stored" within the data storage of a vulnerable web application as valid input.
- How does a Stored XSS attack work?
- It typically unfolds over 4 phases. It begins with: [Survey the application for stored user-controllable inputs] Using a browser or an automated tool, an adversary follows all public links and actions on a web site. They record all the links, the forms, the resources accessed and all other potential entry-points for the web application. The adversary is looking for areas where user input is stored, such as user profiles, shopping carts, file managers, forums, blogs, and logs.
- How do you prevent CAPEC-592?
- Use browser technologies that do not allow client-side scripting.
- What weaknesses does CAPEC-592 target?
- CAPEC-592 exploits 1 CWE weakness, including CWE-79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')).
- How severe is CAPEC-592?
- MITRE rates CAPEC-592 as Very High severity with high likelihood of attack.
References
Attack-pattern data is sourced from the MITRE CAPEC catalog (v3.9). Weakness associations link to the corresponding CWE entries on RadicalNotion.AI.
Defend against CAPEC-592
Track the CVEs and weaknesses attackers exploit with this technique, with AI-written analysis and remediation guidance.