Home > CAPEC List > CAPEC-588: DOM-Based XSS (Version 2.10)  

CAPEC-588: DOM-Based XSS

 
DOM-Based XSS
Definition in a New Window Definition in a New Window
Attack Pattern ID: 588
Abstraction: Detailed
Status: Stable
Completeness: Complete
Presentation Filter:
+ Summary

This type of attack is a form of Cross-Site Scripting (XSS) where a malicious script is inserted into the client-side HTML being parsed by a web browser. Content served by a vulnerable web application includes script code used to manipulate the Document Object Model (DOM). This script code either does not properly validate input, or does not perform proper output encoding, thus creating an opportunity for an adversary to inject a malicious script launch a XSS attack. A key distinction between other XSS attacks and DOM-based attacks is that in other XSS attacks, the malicious script runs when the vulnerable web page is initially loaded, while a DOM-based attack executes sometime after the page loads. Another distinction of DOM-based attacks is that in some cases, the malicious script is never sent to the vulnerable web server at all. An attack like this is guaranteed to bypass any server-side filtering attempts to protect users.

+ Attack Prerequisites
  • An application that leverages a client-side web browser with scripting enabled.

  • An application that manipulates the DOM via client-side scripting.

  • An application that failS to adequately sanitize or encode untrusted input.

+ Typical Severity

Very High

+ Typical Likelihood of Exploit

Likelihood: High

If this weakness is present in an application, then there is a high likelihood that it will be found and exploited. The prevelance of automated dynamic analysis tools (e.g., fuzzers) have made identifying weaknesses like these achievable by even the most basic adversary. Once identified, this type of weakness can often be exploited with minimal trial and error.

+ Examples-Instances

Description

Consider a web application that enables or disables some of the fields of a form on the page via the use of a mode parameter provided on the query string.

http://my.site.com/aform.html?mode=full

The application’s client-side code may want to print this mode value to the screen to give the users an understanding of what mode they are in. In this example, JavaScript is used to pull the value from the URL and update the HTML by dynamically manipulating the DOM via a document.write() call.

<script>document.write("<p>Mode is: " + document.location.href.substring(document.location.href.indexOf('mode=') + 5) + "</p>");</script>

Notice how the value provided on the URL is used directly with no input validation performed and no output encoding in place. A maliciously crafted URL can thus be formed such that if a victim clicked on the URL, a malicious script would then be executed by the victim’s browser:

(Attack)
 
http://my.site.com/aform.html?mode=<script>alert('hi');</script>

Description

In some DOM-based attacks, the malicious script never gets sent to the web server at all, thus bypassing any server-side protections that might be in place. Consider the previously used web application that displays the mode value. Since the HTML is being generated dynamically through DOM manipulations, a URL fragment (i.e., the part of a URL after the '#' character) can be used.

(Attack)
 
http://my.site.com/aform.html#mode=<script>alert('hi')</script>

In this variation of a DOM-based XSS attack, the malicious script will not be sent to the web server, but will instead be managed by the victim's browser and is still available to the client-side script code.

+ Attacker Skills or Knowledge Required

Skill or Knowledge Level: Medium

Requires the ability to write scripts of some complexity and to inject it through user controlled fields in the system.

+ Resources Required

No specialized hardware or software resources are required to launch this type of attack.

+ Probing Techniques

To identify a potentially vulnerable application, review the client-side source code for DOM-related capabilities and look for places that display, store, or use user-supplied information without proper encoding or sanitization.

+ Solutions and Mitigations

Use browser technologies that do not allow client-side scripting.

Utilize proper character encoding for all output produced within client-site scripts manipulating the DOM.

Ensure that all user-supplied input is validated before use.

+ Attack Motivation-Consequences
ScopeTechnical ImpactNote
Confidentiality
Read application data
Read files or directories
A successful DOM-based XSS attack can enable an adversary to exfiltrate sensitive information from the application.
Confidentiality
Authorization
Access_Control
Gain privileges / assume identity
A successful DOM-based XSS attack can enable an adversary to elevate their privilege level and access functionality they should not otherwise be allowed to access.
Confidentiality
Integrity
Availability
Execute unauthorized code or commands
A successful DOM-based XSS attack can enable an adversary run arbitrary code of their choosing, thus enabling a complete compromise of the application.
Integrity
Modify memory
Modify files or directories
Modify application data
A successful DOM-based XSS attack can allow an adversary to tamper with application data.
+ Technical Context
Architectural Paradigms
Web
Frameworks
All
Platforms
All
Languages
Other
+ References
Amit Klein. "DOM Based Cross Site Scripting or XSS of the Third Kind". <http://www.webappsec.org/projects/articles/071105.shtml>.
Jakob Kallin and Irene Lobo Valbuena. "A comprehensive tutorial on cross-site scripting". <https://excess-xss.com/>.
+ Content History
Submissions
SubmitterOrganizationDateSource
CAPEC Content TeamThe MITRE Corporation2017-04-15Internal_CAPEC_Team

More information is available — Please select a different filter.
Page Last Updated or Reviewed: May 01, 2017