Home > CAPEC List > CAPEC-591: Reflected XSS (Version 2.10)  

CAPEC-591: Reflected XSS

 
Reflected XSS
Definition in a New Window Definition in a New Window
Attack Pattern ID: 591
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 “reflected” off a vulnerable web application and then executed by a victim's browser. The process starts with an adversary delivering a malicious script to a victim and convincing the victim to send the script to the vulnerable web application. The most common method of this is through a phishing email where the adversary embeds the malicious script with a URL that the victim then clicks on. In processing the subsequent request, the vulnerable web application incorrectly considers the malicious script as valid input and uses it to creates a reposnse that is then sent back to the victim. To launch a successful Reflected XSS attack, an adversary looks for places where user-input is used directly in the generation of a response. This often involves elements that are not expected to host scripts such as image tags (<img>), or the addition of event attibutes 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.

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

  • An application that fail 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 server-side code may want to display this mode value in the HTML page being created to give the users an understanding of what mode they are in. In this example, PHP is used to pull the value from the URL and generate the desired HTML.

<?php
echo 'Mode is: ' . $_GET["mode"];
?>

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

Reflected XSS attacks can take advantage of HTTP headers to compromise a victim. For example, assume a vulnerable web application called ‘mysite’ dynamically generates a link using an HTTP header such as HTTP_REFERER. Code somewhere in the application could look like:

<?php
echo "<a href=”$_SERVER[‘HTTP_REFERER’]”>Test URL</a>"
?>

The HTTP_REFERER header is populated with the URI that linked to the currently executing page. A web site can be created and hosted by an adversary that takes advantage of this by adding a reference to the vulnerable web application. By tricking a victim into clicking a link that executes the attacker’s web page, such as:

(Attack)
 
"http://attackerswebsite.com?<script>malicious content</script>"

The vulnerable web application (‘mysite’) is now called via the attacker’s web site, initiated by the victim’s web browser. The HTTP_REFERER header will contain a malicious script, which is embedded into the page by the vulnerable application and served to the victim. The victim’s web browser then executes the injected script, thus compromising the victim’s machine.

+ Attacker Skills or Knowledge Required

Skill or Knowledge Level: Medium

Requires the ability to write malicious scripts and embed them into HTTP requests.

+ Resources Required

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

+ Probing Techniques

Locate system capabilities within the web application that display user-supplied information without proper encoding or sanitization.

+ Solutions and Mitigations

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 use.

+ Attack Motivation-Consequences
ScopeTechnical ImpactNote
Confidentiality
Read application data
Read files or directories
A successful Reflected XSS attack can enable an adversary to exfiltrate sensitive information from the application.
Confidentiality
Authorization
Access_Control
Gain privileges / assume identity
A successful Reflected 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 Reflected 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 Reflected attack can allow an adversary to tamper with application data.
+ Technical Context
Architectural Paradigms
Client-Server
n-Tier
Frameworks
All
Platforms
All
Languages
Other
+ References
[R.591.1] Watchfire Research. "XSS vulnerabilities in Google.com". Full Disclosure mailing list archives. Dec 21 2005. <http://seclists.org/fulldisclosure/2005/Dec/1107>.
+ 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