In this article, we will discuss one of the most seen vulnerabilities in web-based applications, which is — Reflected XSS.
What is Cross-Site Scripting:
- Cross-Site Scripting is the most common vulnerability which is identified in most live web-based applications. The web application is the collection of user inputs and search fields. So this is the carrier through which Cross-Site Scripting (XSS) attack happens. In this user input, malicious JavaScript code is inputted by the attacker, which aims to steal user sessions or do cruel code execution.
- The XSS attacks are mostly triggered due to improper validation and sanitization of user inputs. Crafted input can be given to any input field and easily traveled to a web server or database. If the information is handled properly before sending it to the webserver, then the application can be saved from an XSS attack.
Types of Cross-Site Scripting:
- Reflected XSS — Reflected XSS attack occurs when a malicious script is reflected in the website’s results or response.
- Stored XSS — The malicious data is stored permanently on a database and is later accessed and run by the victims without knowing the attack.
- DOM XSS — DOM Based XSS wherein the attacker’s payload is executed due to modifying the DOM “environment” in the victim’s browser used by the original client-side script. The client-side code runs in an “unexpected” manner.
Reflected XSS in Depth:
- Reflected Cross-Site Scripting is the type in which the injected script is reflected off the webserver, like the error message, search result, or any other response. Reflected type attacks are delivered to victims or targets via another path such as email messages or phishing. When the user is tricked into clicking the malicious script or link, then this attack triggers the user’s browser. A simple example of Reflected XSS is the search field.
- An attacker looks for places where user input is used directly to generate a response to launch a successful Reflected XSS attack. 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.
Steps of Reflected XSS
In the above figure:
- The attacker sends a link that contains malicious JavaScript code.
- Malicious Link is executed in normal users at his side on any specific browser.
- After execution, the sensitive data like cookies or session ID is being sent back to the attacker and the normal user is compromised.
Example 1: Consider a web application that takes search string from the user via the search parameter provided on the query string.
http://target.com/aform.html?search=Gaurav
The application server wants to show the search value which is provided by the user on the HTML page. In this case, PHP is used to pull the value from the URL and generate the result HTML
<?php echo ‘You Searched: ‘ . $_GET[“search”]; ?>
Check how the input provided by the user in the URL is directly passed forward with no input validation performed and no output encoding in place. A malicious script thus can be formed such that if a victim clicks on the URL, a malicious script would then be executed by the victim’s browser and send the session values to the attacker.
http://target.com/aform.html?search=<script>alert(‘XSS by Gaurav’);</script>
Example 2: Reflected XSS can also occur when an application employs a dynamic page to display error messages to users. Basically, the page takes an input parameter containing the message’s text and simply displays this text back to the user within the response.
Consider the following URL, which returns the error message
http://target.com/error/5/Error.ashx?message=Sorry%2c+an+error+occurred
If we check the HTML source for the returned page, the application simply copies the value of the message parameter in the URL and inserts it into the error page at a suitable place.
<p>Sorry, an error occurred.</p>
As there is no sanitization and validation performed for the error message attacker can easily insert the malicious script which generates a pop-up dialog.
http://target.com/error/5/Error.ashx?message=<script>alert(“XSS by GAURAV”)</script>
Requesting this link generates an HTML response page that contains the following in place of the original message.
<p><script>alert(“XSS by GAURAV”);</script></p>
Mitigations:
- Try to use browser technologies that do not allow client-side scripting in input fields or URLs.
- Use strict type character and encoding enforcement to avoid XSS.
- Make sure that all the user-supplied inputs are adequately validated before sending them to the server.
Impact of Reflected XSS:
- The attacker can hijack user accounts.
- An attacker could steal credentials.
- An attacker could exfiltrate sensitive data.
- An attacker can steal cookies and Sessions.
- An attacker can quickly obtain access to your other client’s computers.