cross-site scripting Alamy

What Is Reflected XSS?

Reflected XSS attacks are more common than stored XSS attacks and DOM-based XSS attacks because they are easy to execute but hard to detect. However, they can be avoided by vigilant users. Here's how.

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:

  • Stored or persistent XSS attacks, where malicious scripts are injected directly into a website by exploiting a vulnerability within the site. Unlike reflected XSS, this type of attack requires attackers to find a way to upload malicious code to a site.
  • DOM-based attacks, which manipulate DOM data to run malicious code. DOM-based attacks are different from reflected XSS because they rely on changes to DOM information rather than malicious URLs to launch attacks.

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:

  • Website redirects: Attackers could redirect users to malicious websites that host other software designed to steal data or compromise users' devices.
  • Disruptions: Malicious scripts could cause browsers to crash, negatively impact website performance, or create other kinds of user-impacting disruptions.
  • Stolen cookies: Most XSS attacks give attackers access to users' cookies, which they can use to connect to web sessions as if they are those users. In this way, attackers can steal or even modify user data stored within websites and apps.
  • Keylogging: XSS attacks could be used to deploy keylogging software, which records the keystrokes of users and sends them to attackers. By reading keystrokes, attackers can access any data that users input into their devices, such as passwords or messages.

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:

  • Validate user input: Any data that an application accepts — including via URLs — should be validated, and abnormal data within requests should be blocked.
  • Encode output: Output encoding — which means representing output data in a format that is not executable — can reduce the risk of successful XSS attacks because it prevents automatic load-and-execute behavior on the part of browsers.
  • Limit use of user-provided data: In general, the less your website or app processes user-provided data, the better, at least from a security perspective. Don't give users the opportunity to input data except where it's required, and ensure that you use inputted data only for necessary purposes. Don't parse it just to parse it.
  • Block abnormal traffic with firewalls: Modern Web Application Firewall (WAF) tools can detect and block some requests associated with XSS attacks by inspecting the contents of the requests. Although this technique won't prevent all types of attacks, it reduces the risk of successful XSS breaches.

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.

About the author

Christopher Tozzi headshotChristopher Tozzi is a technology analyst with subject matter expertise in cloud computing, application development, open source software, virtualization, containers and more. He also lectures at a major university in the Albany, New York, area. His book, “For Fun and Profit: A History of the Free and Open Source Software Revolution,” was published by MIT Press.
Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish