16f6c0aecf
Inline adoc files when they are included exactly once. Also fix language tags because this inlining gives us better information on what language the code is written in.
57 lines
2.9 KiB
Plaintext
57 lines
2.9 KiB
Plaintext
== Why is this an issue?
|
|
|
|
DOM-based cross-site scripting (XSS) occurs in a web application when its client-side logic reads user-controllable data, such as the URL, and then uses this data in dangerous functions defined by the browser, such as `eval()`, without sanitizing it first.
|
|
|
|
When well-intentioned users open a link to a page vulnerable to DOM-based XSS, they are exposed to several attacks targeting their browsers.
|
|
|
|
|
|
=== What is the potential impact?
|
|
|
|
A well-intentioned user opens a malicious link that injects data into the web application. This data can be text, but also arbitrary code that can be interpreted by the user's browser, such as HTML, CSS, or JavaScript.
|
|
|
|
Below are some real-world scenarios that illustrate some impacts of an attacker exploiting this vulnerability.
|
|
|
|
==== Website defacement
|
|
|
|
An attacker can use the vulnerability to change the target web application's content as they see fit. Therefore, they might replace the website's original content with inappropriate content, leading to brand and reputation damage for the web application owner. It could additionally be used in phishing campaigns, leading to the potential loss of user credentials.
|
|
|
|
==== User impersonation
|
|
|
|
When a user is logged into a web application and opens a malicious link, the attacker can steal that user's web session and carry out unauthorized actions on their account. If the credentials of a privileged user (such as an administrator) are stolen, the attacker might be able to compromise all of the web application's data.
|
|
|
|
==== Theft of sensitive data
|
|
|
|
Cross-site scripting allows an attacker to extract the application data of any user that opens their malicious link. Depending on the application, this can include sensitive data such as financial or health information. Furthermore, by injecting malicious code into the web application, it might be possible to record keyboard activity (keylogger) or even request access to other devices, such as the camera or microphone.
|
|
|
|
==== Chaining XSS with other vulnerabilities
|
|
|
|
In many cases, bug hunters and attackers can use cross-site scripting vulnerabilities as a first step to exploit more dangerous vulnerabilities.
|
|
|
|
For example, suppose that the admin control panel of a web application contains an SQL injection vulnerability. In this case, an attacker could find an XSS vulnerability and send a malicious link to an administrator. Once the administrator opens the link, the SQL injection is exploited, giving the attacker access to all user data stored in the web application.
|
|
|
|
|
|
// How to fix it section
|
|
|
|
include::how-to-fix-it/dom.adoc[]
|
|
|
|
== Resources
|
|
|
|
include::../common/resources/docs.adoc[]
|
|
|
|
include::../common/resources/articles.adoc[]
|
|
|
|
include::../common/resources/standards.adoc[]
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Implementation Specification
|
|
(visible only on this page)
|
|
|
|
=== Message
|
|
|
|
Change this code to prevent execution of arbitrary client-side code.
|
|
|
|
|
|
endif::env-github,rspecator-view[]
|