Introduction

This guide was built over years of working with development teams on fixing real-world vulnerabilities. The following advice is meant to be practical and actionable. Best practices are included, but the main goal is to provide a quick guide for understaffed teams on efficiently improving their product’s security against the actual attacks are prevalent in the wild.

Description

Cross-Site Scripting (XSS) vulnerabilities occur an attacker is able to execute arbitrary JavaScript in a victim’s browser. This can happen when user input is not sanitized. When correcting a Cross-Site Scripting (XSS) vulnerability an important distinction to make is the difference between DOM based XSS, Reflected, and Stored (persistent) XSS. Reflected and Stored XSS are injected into the code by the application’s server, where DOM XSS is pulled into the JavaScript and executed in the user’s browser during runtime. The majority of the time Reflected or Stored XSS is because of an issue in the server-side codebase, while DOM vulnerabilities are in client-side JavaScript.

Quick Fix: Web Application Firewalls (WAF)

• Result: Minimal Risk Mitigation
• Timeframe: 1/2 Hour to 2 Hours
• Delegated to: IT, System Administrators, Network Team

Web application firewalls are not usually mentioned in XSS mitigation guides because it doesn’t prevent most DOM-XSS and, depending on the implementation, can be bypassed with enough effort. It is often referred to as a “band-aid” fix. However, it is included here since a WAF should be a part of a security in depth strategy and it is relatively quick to setup. Especially if your codebase is already in production, this is an option that can be delegated to the IT, Network, or System Administrators to setup while and your developers are fixing the issue in change management.

Short-Term: Codebase Patch

• Result: Spot fixing a specific known vulnerability.
• Timeframe: Depends on change management, from a couple of hours to a day or two.
• Delegated to: Software Engineers, sometimes System Administrators who are flexible

This phase is focused on fixing the known issue. In this case, when there is an identified XSS vulnerability on the system.

General Codebase XSS Patch Workflow

1. Identify location of the issue. This can often be found in a vulnerability report or a scan result. Which parameter, comment box, etc. is not sanitizing user input?
2. Identify the tech stack contributing to this vulnerability. Looking at the injection point, what software does the input pass through?
3. Look at the functions processing the input and identify root cause.

Developing and the fix

Reflected and Stored XSS

Evaluate what input is needed. Is this a function that can be converted to a static list of items to chose from like selecting a country, or does the application process custom user input like a name?

For example, when the user selects a quantity just numbers are expected. It is then simple to restrict user input to integers only. If letters are also needed, determine if symbols are too. Restricting or sanitizing characters works well until the application needs the user to input symbols. Symbols should likely be converted to HTML encoding before inserted into a page.

The hardest endpoints to prevent XSS on are ones that require the user to be able to control some HTML. It is notoriously difficult to secure places like comment boxes and user-generated posts It would be reasonable to expect it to take more time and resources to remediate issues in these locations.

DOM XSS

Look at the endpoint where the XSS executes and identify what JavaScript is processing the user input. One way to do this is by proxying traffic using BurpSuite (there is a free community edition) and then activating the DOM browser extension. Supply input into the suspected vulnerable parameter and look in the console tools to identify how it is being processed.

Once the Javascript framework is identified, see if that version is out of date by looking at its release history. Sometimes updating the framework fixes the issue. Other times the code will have to be patched.

https://nvd.nist.gov/vuln/search

Frameworks

ASP.NET

Microsoft has guides on Preventing XSS in ASP.NET Core. XSS vulnerabilities can arise in ASP.NET codebases. For example, the application is at risk if user input is passed into the ASP.NET Core MVC class HtmlString.

Some options for mitigation include using built in classes from the .NET framework like System.Web.Security.AntiXss.AntiXssEncoder to override System.Web.Util.HttpEncoder. AntiXssEncoder has methods to safely encode strings for use in HTML ,XML, CSS and URLs.

Alternatively, you can use Regular Expressions to validate input. If this method is used then it is recommended the location retested to ensure it is properly restricting characters and not easily bypassed.

Long-Term : Best Practices

• Spend time properly configuring a Content-Security-Policy (CSP) header.
• Update out of date software, sever and client side.
• Review codebase for dangerous use of user input.
• Continually monitor and configure Web Application Firewall (WAF).

Additional Resources

More information on preventing reflected and stored cross-site scripting can be found on OWASP’s cheat sheet and their guidance for DOM-XSS prevention.