What Is a Reflected XSS?

An XSS allows an attacker to inject a script into the content of a website or app. When a user visits the infected page, the script will execute in the victim’s browser. This allows attackers to steal private information like cookies, account information, or perform custom operations while impersonating the victim’s identity.

A reflected XSS (also called a non-persistent XSS attack) is a specific type of XSS whose malicious script bounces off of another website to the victim’s browser. It is passed in the query, typically, in the URL. It makes exploitation as easy as tricking a user to click on a link.

Compared to stored XSS, non-persistent XSS only requires the malicious script to be added to a link and that a user clicks on it.

Why Reflected XSS Matter?

Even if reflected XSS offers less power to an attacker, they are more common than stored XSS. This is because exploiting an XSS just requires users to click on the malicious link. It’s easy to include this link in emails, forums, etc.

As an attacker, being able to exploit a reflected XSS still means that they can execute arbitrary JavaScript in the vulnerable web application. This makes any programmatically-triggerable action of the application usable by the attacker. For instance, Bitcoin exchange users could transfer Bitcoins to arbitrary users.

The JavaScript code is also run inside the victim’s browser. This allows the exploitation of browser-based, OS-based, or browser’s plugin-based vulnerabilities. They let the attacker own the machine — usually making it a member of a botnet.

Since reflected XSS typically involves some social engineering (to trick users into clicking a malicious link), they are often conducted in order to directly steal a user’s credentials by crafting a fake login page. The reflected nature of the attack makes sure that everything is valid from the user point of view: HTTPS, URL (at least the beginning), even the password manager will recognize the website and fill out the forms.

How to Avoid XSS Vulnerabilities in Your Code?

XSS vulnerabilities come from a lack of data escaping. Escaping should be performed when user inputs are used at the templating engine level. That’s the only point the developer knows in a context the user data will appear.

Let’s take a simple example. The following is a typical Ruby on Rails template where user data is provided in many different places. The same stands for any templating engine in any other language.

<div>
  <h1>Blog post: <%= @post.title %></h1> (1)
  <br />
  <a href=“<%= @post.url %>”>Click here to see the full story</a> (2)
  <script>
    record_post_view(@post.id); (3)
  </script>
  <div id=“footer” <%= @post.footer_attr %>>&copy; 2018</div> (4)
</div>

In this example, we can see four distinct positions where data is added to the template. They all require different escaping.

XSS can be triggered in each of these four places. The following table shows which data is needed to run the alert(0) JavaScript code at each position:

By leveraging the templating engine semantic, we know what data is dynamically added to the static, developer-defined HTM. We then know how the code should be escaped.

So data escaping is the key here. It requires developers to ensure they insert data in a template that will be escaped when the template is generated.

How to Block XSS Attacks in Real-Time?

The Legacy Way – Web Application Firewalls

Standard Web Application Firewalls (WAF) or even NextGen WAF work all the same way to detect and block attackers: they will look at flat network data.

The goal of a WAF is to try to match an incoming HTTP request with one of the signature or pattern of attacks it has in its database.

WAF has several issues:

• You need to redirect your whole traffic. In terms of data privacy and latency, we’ve seen better 

• If the XSS doesn’t match one of the known attacks in your signature database, it won’t be caught. It’s never up to date and can be easily bypassed.

• The amount of false positives (wrong triggers) these WAF generate makes it really painful to use in protection or even monitoring mode.

Trying to block attacks triggering vulnerabilities inside the application from outside the app just doesn’t make any sense. You lack all the technical context of a request. Would you monitor the performance of a specific function of your app by putting a probe outside of it?

The Legit Approach – Detecting Attacks From the Inside

As often with web applications vulnerabilities, there is no better place for stopping such attacks reliably than by observing what happens inside the application.

If we look at the previous code example, the @post.title  is non-escaped. If reflected from the URL, it will lead to a reflected XSS:

<h1>Blog post: <%= raw @post.title %></h1>

To detect such non-escaped data, you need to place hooks inside the templating engine. If you combine this with the parameters coming from the client in the URL, the HTTP headers, or in the request’s body, you can accurately detect reflected XSS without triggering false positives.