Reflected XSS Vulnerability In Depth

In this article, we will discuss one of the most seen vulnerabilities in web-based applications, which is:- Reflected XSS.

Cross-Site Scripting :

Cross-site scripting(XSS) is a classic well-known type of attack that is possible because some software applications take user input in an insecure way. This happens via search fields, survey forms, cookies, and online web forms. XSS attacks can involve a wide range of malicious activities, including data theft, user session hijacking, malicious code execution, or they may be used as part of a phishing scam.With the introduction of rich internet applications (RIA), which rely heavily on client-side scripts and AJAX calls, the detection and prevention of cross-site scripting attacks have become even more complicated. Cross-site scripting is predicated on the need of websites to receive input from users, and since you’ll find fewer and fewer websites that unilaterally deliver content to visitors without offering some sort of interaction mechanism, most websites are susceptible to have XSS vulnerabilities in one way or another. According to a survey by WhiteHat Security, 70% of website vulnerabilities are XSS-related.

Types of Cross-Site Scripting :

Reflected XSS → This attack occurs when a malicious script is reflected in the website’s results.Stored XSS → The malicious data is stored permanently on a database and is later accessed and run by the victims without having any knowledge of the attack.DOM XSS → DOM Based XSS wherein the attacker’s payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client-side script so that the client-side code runs in an “unexpected” manner.

Reflected XSS in Depth :

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 response 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 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.Reflected XSS Steps

In the above fig, we can see that in:-

Step 1:- Attacker sends link which contains malicious Javascript code.

Step 2:- Malicious Link is executed in normal user at his side on any specific browser.

Step 3:- After execution, the sensitive data like cookies or session ID is being sent back to the attacker and the normal user is compromised.

Example :

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:

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

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:

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.

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.

Impact of Reflected XSS :

Perform any action within the application that the user can perform.View any information that the user can view.Modify any information that the user can modify.Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.