This attack is a form of Cross-Site Scripting (XSS) where malicious scripts are embedded in elements that are not expected to host scripts such as image tags ( ), comments in XML documents ( ), etc. These tags may not be subject to the same input validation, output validation, and other content filtering and checking routines, so this can create an opportunity for an adversary to tunnel through the application's elements and launch a XSS attack through other elements. As with all remote attacks, it is important to differentiate the ability to launch an attack (such as probing an internal network for unpatched servers) and the ability of the remote adversary to collect and interpret the output of said attack.

How does a XSS Targeting Non-Script Elements attack work?

It typically unfolds over 4 phases. It begins with: [Survey the application for user-controllable inputs] Using a browser or an automated tool, an adversary records all entry points for inputs that happen to be reflected in a client-side non-script element. These non-script elements can be located in the HTML content (head, body, comments), in an HTML tag, XML, CSS, etc.

How do you prevent CAPEC-18?

In addition to the traditional input fields, all other user controllable inputs, such as image tags within messages or the likes, must also be subjected to input validation. Such validation should ensure that content that can be potentially interpreted as script by the browser is appropriately filtered.

What weaknesses does CAPEC-18 target?

CAPEC-18 exploits 1 CWE weakness, including CWE-80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)).

How severe is CAPEC-18?

MITRE rates CAPEC-18 as Very High severity with high likelihood of attack.

CAPEC-18: XSS Targeting Non-Script Elements

Overview

CAPEC-18 (XSS Targeting Non-Script Elements) is a detailed-level attack pattern catalogued by MITRE in the Common Attack Pattern Enumeration and Classification (CAPEC). It describes a recurring method attackers use to exploit software weaknesses.

How the attack works

The phases an attacker typically follows to carry out this attack.

Step 1
Explore
[Survey the application for user-controllable inputs] Using a browser or an automated tool, an adversary records all entry points for inputs that happen to be reflected in a client-side non-script element. These non-script elements can be located in the HTML content (head, body, comments), in an HTML tag, XML, CSS, etc.
- Use a spidering tool to follow and record all non-static links that are likely to have input parameters (through forms, URL, fragments, etc.) actively used by the Web application.
- 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 2
Experiment
[Probe identified potential entry points for XSS vulnerability] The adversary uses the entry points gathered in the "Explore" phase as a target list and injects various common script payloads to determine if an entry point actually represents a vulnerability and to characterize the extent to which the vulnerability can be exploited.
- Manually inject various script payloads into each identified entry point using a list of common script injection probes that typically work in a client-side non-script elements context and observe system behavior to determine if script was executed. Since these probes may have to be injected in many different types of non-script elements, they should cover a variety of possible contexts (CSS, HTML tag, XML, etc.).
- Use an automated injection attack tool to inject various script payloads into each identified entry point using a list of common script injection probes that typically work in a client-side non-script elements context and observe system behavior to determine if script was executed. Since these probes may have to be injected in many different types of non-script elements, they should cover a variety of possible contexts (CSS, HTML tag, XML, etc.).
- Use a proxy tool to record results of the created requests.
Step 3
Experiment
[Create malicious XSS content] Once the adversary has determined which entry points are vulnerable to XSS, they will interact with the web application to store the malicious content. Because of the nature of this attack, it is mostly carried out through stored XSS, although it is possible to perform this attack using reflected XSS. 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, disguised as a non-script element, 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 4
Exploit
[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

The target client software must allow the execution of scripts generated by remote hosts.

Skills required

Low skill: To achieve a redirection and use of less trusted source, an adversary can simply edit content such as XML payload or HTML files that are sent to client machine.
High skill: Exploiting a client side vulnerability to inject malicious scripts into the browser's executable process.

Resources required

Ability to include malicious script in document, e.g. HTML file, or XML document. Ability to deploy a custom hostile service for access by targeted clients. Ability to communicate synchronously or asynchronously with client machine

Consequences

What a successful CAPEC-18 attack can achieve.

Execute Unauthorized Commands

Affects: Confidentiality, Integrity, Availability

Run Arbitrary Code

Read Data

Affects: Confidentiality

How to mitigate it

Defenses that reduce the risk of CAPEC-18.

In addition to the traditional input fields, all other user controllable inputs, such as image tags within messages or the likes, must also be subjected to input validation. Such validation should ensure that content that can be potentially interpreted as script by the browser is appropriately filtered.
All output displayed to clients must be properly escaped. Escaping ensures that the browser interprets special scripting characters literally and not as script to be executed.

Examples

An online discussion forum allows its members to post HTML-enabled messages, which can also include image tags. A malicious user embeds JavaScript in the IMG tags in their messages that gets executed within the victim's browser whenever the victim reads these messages. When executed within the victim's browser, the malicious script could accomplish a number of adversary objectives including stealing sensitive information such as usernames, passwords, or cookies.

The CWE weaknesses that CAPEC-18 exploits.

CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

How this attack relates to others in the CAPEC hierarchy.

Parent

Frequently asked questions

Common questions about CAPEC-18.

What is CAPEC-18?: This attack is a form of Cross-Site Scripting (XSS) where malicious scripts are embedded in elements that are not expected to host scripts such as image tags ( ), comments in XML documents ( ), etc. These tags may not be subject to the same input validation, output validation, and other content filtering and checking routines, so this can create an opportunity for an adversary to tunnel through the application's elements and launch a XSS attack through other elements. As with all remote attacks, it is important to differentiate the ability to launch an attack (such as probing an internal network for unpatched servers) and the ability of the remote adversary to collect and interpret the output of said attack.
How does a XSS Targeting Non-Script Elements attack work?: It typically unfolds over 4 phases. It begins with: [Survey the application for user-controllable inputs] Using a browser or an automated tool, an adversary records all entry points for inputs that happen to be reflected in a client-side non-script element. These non-script elements can be located in the HTML content (head, body, comments), in an HTML tag, XML, CSS, etc.
How do you prevent CAPEC-18?: In addition to the traditional input fields, all other user controllable inputs, such as image tags within messages or the likes, must also be subjected to input validation. Such validation should ensure that content that can be potentially interpreted as script by the browser is appropriately filtered.
What weaknesses does CAPEC-18 target?: CAPEC-18 exploits 1 CWE weakness, including CWE-80 (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)).
How severe is CAPEC-18?: MITRE rates CAPEC-18 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.