What Is XSS?: An Overview

We recently covered the most up-to-date list of OWASP Top 10 vulnerabilities. In subsequent future posts, we’ll be discussing some of those more prominent vulnerabilities in a little more depth. Starting with cross-site scripting (XSS), the common cold of security vulnerabilities.

XSS AT ITS CORE

XSS is a type of injection attack, which is another finding on the OWASP Top 10 vulnerabilities list. XSS involves injecting malicious code into a website that would otherwise appear harmless (e.g., a popular news site). Once a user navigates to this website, the site performs an action on the user's behalf without their knowledge. This client-side code can perform any action the user can in the affected application's domain within the user's web browser. (To see an example of this in action, check out our advisory on high-risk vulnerabilities in the Big Monitoring Fabric application. The XSS vulnerability could allow an unauthenticated remote attacker administrative access in the application.)

To better imagine XSS, think of a rental car. You rent the car and then do something strange to it before you return it to the car rental agency. If the agency neglects to do their due diligence before the car goes out to another customer, that customer will suffer as a result. This is similar to XSS in that if the app server doesn’t do “contextual output encoding” when the inputs cross trust boundaries, all visitors for that page are potentially affected.

Now, let’s sharpen our lens on XSS a little more.

XSS VARIETIES

Reflected XSS (aka Nonpersistent)

This is one of the most common forms of XSS out there. It occurs when malicious code is “reflected” unaltered from a web application executing in a user’s browser. In other words, that malicious code is reflected – or contained – in the application's response to the malicious requests. Users often are enticed to click a malicious link via phishing, and once they click, the exploit unfolds.

Stored XSS (aka Persistent)

Stored XSS means that the malicious code is stored within the application; whenever a user navigates to the affected webpage, the script will execute. So instead of targeting a single potential victim – everyone who navigates to that affected webpage could be compromised too (and imagine how disastrous that could be for a high-profile website.) Of all the XSS varieties thus far, this one has the ability to inflict the most damage.

DOM-Based XSS

This strain of XSS occurs in the document object model (DOM); it’s not apparently visible in the HTML. The primary difference of this XSS from its counterparts is the malicious client-side code is not visible within the application's response. Exploitation of this XSS works in the same manner as the other varieties; attackers would generally attempt to steal user sessions, force actions on their behalf, or perform a host of malicious client-side actions.

HOW TO DIAGNOSE AND PREVENT XSS

Try Burp Suite Professional or XSS Hunter. While you’ll find a great deal of “XSS scanners” online, a lot of them are nothing more than snake oil. Your two best options to scan for XSS vulnerabilities will be the tried-and-true Burp Suite Professional or the tool XSS Hunter.

Conduct a Penetration Test. We may be biased, but the gold-standard method to prevent XSS attacks is to work with a third-party vendor to perform a penetration test. This way, you’ll receive a comprehensive list of the vulnerabilities contained within your application.

As far as prevention goes, you can do the following to ensure your application stays as secure as it can within reason:

• Institute contextual output encoding. Contextual output encoding is the most reliable solution to combat XSS. It can help take script code and convert it into harmless output for any application that includes user-supplied data. This reduces the success of XSS attacks.
• Use modern browser headers such as Content-Security-Policy (CSP). This can provide extremely robust protection against XSS as well as other injection attacks.
  - Ensure the CSP never allows the use of unsafe content sources. This can include sources like unsafe-inline and unsafe-eval.
  - Avoid hosting user-supplied files on origins that are whitelisted by active content directives. As well, avoid wildcard sources whenever possible.
  - Configure the CSP to never allow data as active content sources. And if you find a content source is not used by the application, set the corresponding content source to none.
• Consider which encodings to nest. For example, HTML encoding a value may fail in certain contexts such as an HTML attribute since it will be decoded prior to interpretation as a value.
• Implement regular security audits and penetration tests (if you’re not doing so already).
• And as always, remediate vulnerabilities in a timely fashion.

XSS vulnerabilities are extremely common among applications. But not all is lost, if you follow the tips and best practices we’ve outlined here, you can prevent many of these attacks and protect your users.

Any suggestions for the next OWASP Top 10 vulnerability we explain? Let us know - @bishopfox on Twitter, #AttacksExplained. Special thanks to Chris Davis!