What Is Reflected XSS?

Reflected XSS attacks are one of the most common techniques that threat actors use to inject malicious scripts into websites. From there, the attackers can steal sensitive data, deface websites, or potentially even capture the keystrokes of affected users.

The good news is that reflected XSS attacks are relatively easy to prevent. This overview describes how reflected XSS attacks work, how to detect this type of XSS attack, and best practices for mitigating the risk of websites or apps you develop falling victim to reflected XSS.

What Is Reflected XSS?

Reflected cross-site scripting, or XSS, is a type of attack in which malicious actors deploy malicious scripts onto users' computers through specially formatted links.

To launch a reflected XSS attack, attackers first create a link like the following:

http://example.com/index.php?malicious_code

When a user clicks the link, his or her browser will run the malicious code that is embedded into the URL, if the code is not detected first.

This type of XSS attack is called a reflected attack because the malicious code is "reflected" off of a third-party website (which is example.com in the example above). The attackers don't actually need to compromise the website; all they need to do is craft a URL that contains malicious code.

Related:Cross-Site Scripting Attacks: How to Protect Your Website

Reflected XSS attacks are also sometimes called non-persistent attacks because they don't require malicious code to be stored persistently on any website. The code is instead embedded into URLs.

Reflected XSS: Real-World Examples

The reflected XSS example above is overly simplistic. In the real world, you wouldn't encounter a URL that is as obviously malicious as http://example.com/index.php?malicious_code (or if you did, the chances that your browser would actually execute the code are very low).

Instead, actual reflected XSS attacks rely on more sophisticated means for injecting malicious code into browsers. For example, a real-world reflected XSS attack against Google DevSite allowed attackers to run JavaScript by inserting malicious code into URLs based on the domains http://cloud.google.com and http://developers.google.com. The attack was enabled by a flaw in the way that the server-side application validated data input.

A similar reflected XSS vulnerability was reported in parts of the amazon.com website. The flaw allowed researchers to redirect site visitors to external URLs and steal cookies.

These are just a couple of examples of reflected XSS attacks at work in the real world. Google and Amazon are no more guilty than any other company, large or small, of deploying software that is vulnerable to XSS. On the contrary, XSS attacks are pervasive, and if companies that take cybersecurity as seriously as Google and Amazon can fall victim to reflected XSS, anyone can.

Reflected XSS vs. Persistent XSS and Other XSS Attacks

Reflected XSS is only one type of XSS attack. Other common XSS attack techniques include:

Why Are Reflected XSS Attacks Popular?

Although reflected XSS attacks represent only one type of XSS attack, reflected XSS is a particularly popular attack method for threat actors, for several reasons.

One is that this type of XSS attack is relatively easy to execute. Attackers don't need to locate a vulnerability within a website or app, as they would in the case of a stored XSS attack. Nor do they have to assess the complex DOM structure of a site to locate a vulnerability, as with DOM-based attacks. Instead, attackers simply have to craft malicious URLs and find a place to host them — such as social media sites or emails.

Another advantage of reflected XSS from an attacker's perspective is that if the website that attackers associated with the malicious link is a site that users trust, users may accept any warnings that their browser presents about running the malicious code. In other words, because users believe that the script is associated with a site that they think is secure, they are more likely to ignore any security warnings than they would when clicking links on untrusted sites. This is part of the reason why XSS attacks are so popular among threat actors.

Finally, reflected XSS attacks can be difficult to detect because attackers can obfuscate malicious code in ways that make it hard for browsers and firewalls to block. Most reflected XSS attacks don't use a URL as simple as http://example.com/index.php?malicious_code. Instead, they might encode the malicious commands in hexadecimal format or bury them within very long data strings to evade XSS discovery engines.

Consequences of Reflected XSS Attacks

Reflected XSS attacks — and XSS attacks in general — can lead to a variety of security problems, including:

Keep in mind that although the direct impact of XSS attacks falls mostly on users, XSS attacks can be harmful for businesses, too. Businesses that deploy websites or apps that are associated with XSS attacks may suffer harm to their reputation.

Best Practices for Preventing Reflected XSS Attacks

The best way to prevent reflected XSS attacks is to design applications to be secure from the start. In particular, developers should:

Beyond these techniques, developers and admins can encourage end users to run secure browsers. Modern web browsers include filters that are designed to detect most types of reflected XSS attacks (although as with WAF-based detection, there is no guarantee that your web browser will detect all attempted XSS attacks), so ensuring that browsers are up-to-date helps reduce the risk of successful XSS attacks on user devices. Of course, you can't always control which browsers your users run, so attempting to block XSS at the browser level should not be your primary means of preventing reflected XSS attacks.

Testing for Reflected XSS

While endeavoring to write code that properly filters and validates user-provided data is the first step in protecting against XSS, developers can also take advantage of tools that automatically scan applications to detect XSS risks.

Free XSS scanners are available on GitHub and other websites that host open source software. In addition, a variety of vendors sell cybersecurity tools that can scan application source code and/or binaries for XSS risks.

Another way to test for reflected XSS is to create an inventory of all input vectors that exist within an application or website. In other words, developers can determine all parts of a website that can accept user-provided data. Then, they can feed data that is designed to simulate malicious input into the vectors. If the input is accepted, they'll know that they have a potential XSS vulnerability.

Conclusion

Due to their ease of execution and the fact that they can be difficult to detect, reflected XSS attacks are one of the most common types of XSS attacks that websites and apps face today.

Although there is no simple way to guarantee protection against all types of reflected XSS risks, there are several best practices that can minimize the chances of a successful reflected XSS attack. Properly validating and filtering input data is the most important step, but output encoding and defenses within the network and browsers can help to stop reflected XSS, too.