Sanitize Input for Reflected/Stored XSS

There’s a reason why XSS vulnerabilities are so common in the wild: they’re difficult to get rid of. Sanitizing sounds simple in principle, but escaping and disallowing characters can get complicated quickly. Let’s look at various rules from the OWASP XSS Prevention Cheat Sheet,^[68] which you should keep in mind when building your site.

But first, a small test: in the following code example there’s an HTML document—actually, an Embedded JavaScript^[69] (EJS) template. Do you know where you could in theory put unsafe content and where you should never put unsafe content?

Did you find all of them? Are you confident? If not, then keep reading.

It turns out there are some locations in an HTML document where sanitizing is so difficult that you’d be better off avoiding them entirely. Unless, of course, you want attackers to target your customers.

​①​

Inside HTML comments (<%- 1 %>)

​①​

Directly inside style attribute (<%- 3 %>)

​②​

As a tag name (<%- 4 %>)

​③​

As an attribute name (<%- 7 %>)

​①​

Directly inside a script attribute (<%- 11 %>)

By avoiding these locations you give your website a fighting chance against XSS. Now let’s look at where you potentially can put unsafe data without causing too much harm:

​①​

As CSS values (<%- 2 %>)

​①​

As URL parameters (<%- 5 %>)

​②​

Inside HTML elements (<%- 6 %>)

​③​

Inside common quoted HTML attributes (<%- 8 %>)

​④​

Inside JavaScript data values in attributes (<%- 9 %>)

​①​

Inside JavaScript data values in script elements (<%- 10 %>)

All of these locations require their own specific form of sanitizing, so we’ll go over them one by one. And to be safe you should avoid any other locations not mentioned here unless you do thorough research first and confirm it’s okay.

Let’s start sanitizing!

node-esapi
	Due to my inability to find context-specific escaping libraries for Node, I’ve ported the ESAPI4JS (Enterprise Security API for JavaScript) encoder module. This module is called ‘node-esapi‘.[70] ESAPI4JS was developed by OWASP and implements the escape rules described in this chapter. As such we’ll be using it as our sanitizing library in the examples.

Rule 1: Escape untrusted data inserted into HTML element content.

When you insert data into an HTML body, you have to HTML escape it. This includes normal tags as well, such as div, p, b, and section. Some template engines like jade^[71] do this automatically. However, this is absolutely not sufficient for other HTML contexts, and you have to be certain of your template engine if you want to rely on it to handle encoding automatically:

You can do this with the ESAPI library:

HTML escaping means that you escape the five characters important for XML^[72]— &, <, >, ", ’—and also the forward slash, /, because it helps end HTML elements. You can use the following conversion table:

Rule 1.1: Sanitize HTML markup with a library designed for the job.

When your application lets users enter HTML content, you can’t just trust it, but you can’t simply use encoding because it would break the HTML. Use the library designed for the task.

Several different modules in Node.js were written specifically for this purpose; I will highlight two of them:

• Bleach^[73]: designed for easy HTML sanitizing. It supports both whitelist and blacklist sanitizing and has other options as well. Unfortunately this module hasn’t been updated for over a year.
• Sanitizer^[74]: a port of the Caja-HTML-Sanitizer.^[75] It’s a thorough HTML sanitizer developed by Google that also supports various options.

Rule 2: Escape untrusted data inserted into HTML attributes.

When you insert untrusted data into common HTML attributes like value, width, and name, you have to encode accordingly. Surround the attribute value with either single or double quotes:

The following shows how to apply the rule with the ESAPI library:

When escaping for HTML attributes you need to escape all characters, except for alphanumeric characters, with ASCII values less than 256 with the &#xHH; format (or a named entity if available) to prevent switching out of the attribute.

The reason this rule is so broad is that developers frequently leave attributes unquoted. Properly quoted attributes can only be escaped with the corresponding quote. Unquoted attributes, however, can be broken out of with many characters, including [space] % * + , - / ; < = > ^ and |.

This rule does not cover complex attributes like href, src, style or any event handler like onclick. Event handler attributes follow rule 3.

Rule 3: Escape untrusted data inserted into JavaScript data values.

This rule applies to dynamically created JavaScript code—both script blocks and event handlers. The only place to put data in this case is in the quoted data values. Any other JavaScript context is dangerous—it’s easy to switch execution context, because there are many characters that allow the attacker to do so:

Always quote data values because it drastically limits the possible context escape values attackers could use:

Some JavaScript functions can never safely use untrusted data as input, as shown here:

You can encode for JavaScript using the ESAPI library:

When escaping for JavaScript you need to escape all characters, except for alphanumeric characters less than 256, with the &#xHH; format to prevent switching out of the data value into the script context or into another attribute.

Do not use any escaping shortcuts like \" because the quote character will wind up being matched by the HTML attribute parser, which runs first. Escaping shortcuts are also susceptible to escape-the-escape attacks, where the attacker sends \" and the vulnerable code turns that into \\" to enable the quote.

If an event handler is properly quoted, breaking out requires you to have the corresponding quote. This rule is intentionally broad because event handler attributes are often left unquoted. Unquoted attributes can be broken out of with many characters, including [space] % * + , - / ; < = > ^ and |.

Also, a </ script> closing tag will close a script block even though it’s inside a quoted string because the HTML parser runs before the JavaScript parser.

Rule 3.1: Escape JSON values in an HTML context and read the data with JSON.parse.

In Web 2.0 applications you often generate data by the application and transfer it through JSON. The data can be received with AJAX calls, but that’s not always efficient. You often load an initial block of JSON on the page to act as the base data. Let’s look at how you can do this securely.

First of all, when asking for JSON data from the server, ensure that the HTTP Content-Type header is set correctly to application/json so that the browser doesn’t accidentally try to interpret the content as HTML.

With express, this is handled automatically when you send a response with res.json instead of res.send, because it sets the header internally:

A common anti-pattern when serving JSON as part of the original HTML looks like the following:

The problem with this approach is that it’s possible to change the execution context, because the HTML interpreter runs before the JavaScript interpreter. Instead, I recommend that you separate the server-side data without breaching context barriers. Place JSON into HTML as a normal element and then use JavaScript to parse the contents:

Rule 4: Escape and validate untrusted data inserted into CSS property values.

Although it might not seem like it, CSS (Cascading Style Sheets) can be used as an XSS attack vector because CSS can execute and include scripts. Here’s an example of how CSS is used in an attack:

When you use untrusted data to construct CSS or set style properties on elements, make sure you perform proper validation checks. Don’t use untrusted data for anything other than property values. Don’t put untrusted data into complex property values such as url and behavior. I suggest also avoiding the Internet Explorer–specific expression property since it allows JavaScript.

Even if you escape CSS, you still have to ensure all URLs start with http: or https: and not with javascript:. Property values should never start with expression.

Here’s the same example, using the ESAPI library:

When escaping for CSS, remember to escape all characters, except for alphanumeric characters, with ASCII values less than 256 with the &#xHH; escaping format. As mentioned in a previous rule, do not use any escaping shortcuts like " because the quote character may be matched by the HTML attribute parser instead. These shortcuts are also susceptible to escape-the-escape attacks where \" turns into \\".

If an attribute is quoted, breaking out requires the corresponding quote. All attributes should be quoted, but your encoding should be strong enough to prevent XSS when untrusted data is placed in unquoted contexts.

Unquoted attributes can be broken out of with many characters, including [space] % * + , - / ; < = > ^ and |. Also, the </ style> tag will close the style block even though it’s inside a quoted string because the HTML parser runs before the CSS parser.

Please note that aggressive CSS encoding and validation are recommended to prevent XSS attacks for both quoted and unquoted attributes.

Rule 5: Escape untrusted data inserted into HTML URL parameter values.

This is one of the easiest rules to apply. When you want to put data into HTTP GET parameters, URL escape it!

You can do this easily with the ESAPI library:

When escaping for URL, escape all characters, except for alphanumeric characters, with ASCII values less than 256 with the %HH escaping format. Don’t include untrusted data in data: URLs because there’s no good way to disable those attacks with escaping.

All attributes should be quoted. Unquoted attributes can be broken out of with many characters, including [space] % * + , - / ; < = > ^ and |. Note that entity encoding is useless in this context.

Be careful with URL encoding and relative URLs. If the user input is meant to be placed into href or src or other URL-based attributes, then it should be validated beforehand to make sure it doesn’t point to an unexpected protocol or script file. After that, encode URLs based on context, like all other data.

For example, when inserting into a href attribute, you attribute encode it.

How All the Rules Come Together

To avoid XSS attacks when rendering templates on the server side, you should always be careful with unsafe content. You must encode depending on the location where the content is being inserted. Using the wrong encoding format doesn’t help you, and there’s no one-size-fits-all rule that you can apply. Look at the following example to see how you can combine all the methods in one place: