DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Data Engineering
  3. Data
  4. Reflected XSS Explained: How to Prevent Reflected XSS in Your App

Reflected XSS Explained: How to Prevent Reflected XSS in Your App

Learn more about how you can prevent reflected XSS in your app.

Paul Bleicher user avatar by
Paul Bleicher
·
Apr. 18, 19 · Presentation
Like (3)
Save
Tweet
Share
13.72K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Reflected XSS illustration

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:

Place Attack payload Rails escaping method
@post.title script>alert(0);</script ERB::Util.html_escape
@post.url “ onblur=javascript:alert(0) “ or “> ERB::Util.html_escape
@post.id 123); alert(0); None – ensure @post.id is an integer
@post.footer_attr onblur=javascript:alert(0) None – don’t allow a user to inject arbitrary attributes

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.

app Web application Data (computing)

Published at DZone with permission of Paul Bleicher. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Unlocking the Power of Polymorphism in JavaScript: A Deep Dive
  • How to Develop a Portrait Retouching Function
  • What Should You Know About Graph Database’s Scalability?
  • Spring Cloud: How To Deal With Microservice Configuration (Part 1)

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: