Recall that an XSS attack is a type of code injection: user input is mistakenly interpreted as malicious program code. In order to prevent this type of code injection, secure input handling is needed. For a web developer, there are two fundamentally different ways of performing secure input handling:

• Encoding, which escapes the user input so that the browser interprets it only as data, not as code.

• Validation, which filters the user input so that the browser interprets it as code without malicious commands.

While these are fundamentally different methods of preventing XSS, they share several common features that are important to understand when using either of them:

• Context Secure input handling needs to be performed differently depending on where in a page the user input is inserted.

• Inbound-outbound Secure input handling can be performed either when your website receives the input (inbound) or right before your website inserts the input into a page (outbound).

• Client-server Secure input handling can be performed either on the client-side or on the server-side, both of which are needed under different circumstances.

Before explaining in detail how encoding and validation work, we will describe each of these points.

There are many contexts in a web page where user input might be inserted. For each of these, specific rules must be followed so that the user input cannot break out of its context and be interpreted as malicious code. Below are the most common contexts:

In all of the contexts described, an XSS vulnerability would arise if user input were inserted before first being encoded or validated. An attacker would then be able to inject malicious code by simply inserting the closing delimiter for that context and following it with the malicious code.

For example, if at some point a website inserts user input directly into an HTML attribute, an attacker would be able to inject a malicious script by beginning his input with a quotation mark, as shown below:

This could be prevented by simply removing all quotation marks in the user input, and everything would be fine—but only in this context. If the same input were inserted into another context, the closing delimiter would be different and injection would become possible. For this reason, secure input handling always needs to be tailored to the context where the user input will be inserted.

Instinctively, it might seem that XSS can be prevented by encoding or validating all user input as soon as your website receives it. This way, any malicious strings should already have been neutralized whenever they are included in a page, and the scripts generating HTML will not have to concern themselves with secure input handling.

The problem is that, as described previously, user input can be inserted into several contexts in a page. There is no easy way of determining when user input arrives which context it will eventually be inserted into, and the same user input often needs to be inserted into different contexts. Relying on inbound input handling to prevent XSS is thus a very brittle solution that will be prone to errors. (The deprecated "magic quotes" feature of PHP is an example of such a solution.)

Instead, outbound input handling should be your primary line of defense against XSS, because it can take into account the specific context that user input will be inserted into. That being said, inbound validation can still be used to add a secondary layer of protection, as we will describe later.

In most modern web applications, user input is handled by both server-side code and client-side code. In order to protect against all types of XSS, secure input handling must be performed in both the server-side code and the client-side code.

• In order to protect against traditional XSS, secure input handling must be performed in server-side code. This is done using any language supported by the server.

• In order to protect against DOM-based XSS where the server never receives the malicious string (such as the fragment identifier attack described earlier), secure input handling must be performed in client-side code. This is done using JavaScript.

Now that we have explained why context matters, why the distinction between inbound and outbound input handling is important, and why secure input handling needs to be performed in both client-side code and server-side code, we will go on to explain how the two types of secure input handling (encoding and validation) are actually performed.

Encoding is the act of escaping user input so that the browser interprets it only as data, not as code. The most recognizable type of encoding in web development is HTML escaping, which converts characters like < and > into &lt; and &gt;, respectively.

The following pseudocode is an example of how user input could be encoded using HTML escaping and then inserted into a page by a server-side script:

print "<html>"
print "Latest comment: "
print encodeHtml(userInput)
print "</html>"

If the user input were the string <script>…</script>, the resulting HTML would be as follows:

<html>
Latest comment:
&lt;script&gt;...&lt;/script&gt;
</html>

Because all characters with special meaning have been escaped, the browser will not parse any part of the user input as HTML.

When performing encoding in your client-side code, the language used is always JavaScript, which has built-in functions that encode data for different contexts.

When performing encoding in your server-side code, you rely on the functions available in your server-side language or framework. Due to the large number of languages and frameworks available, this tutorial will not cover the details of encoding in any specific server-side language or framework. However, familiarity with the encoding functions used on the client-side in JavaScript is useful when writing server-side code as well.

</file>

In this example policy, the page is subject to the following restrictions:

• Scripts can be downloaded only from the host serving the page and from scripts.example.com.

• Audio and video files cannot be downloaded from anywhere.

• Image files can be downloaded from any host.

• All other resources can be downloaded only from the host serving the page and from any subdomain of example.com.

As of June 2013, Content Security Policy is a W3C candidate recommendation. It is being implemented by browser vendors, but parts of it are still browser-specific. In particular, the HTTP header to use can differ between browsers. Before using CSP today, consult the documentation of the browsers that you intend to support.

• XSS is a code injection attack made possible through insecure handling of user input.

• A successful XSS attack allows an attacker to execute malicious JavaScript in a victim's browser.

• A successful XSS attack compromises the security of both the website and its users.

• There are three major types of XSS attacks:

• Persistent XSS, where the malicious input originates from the website's database.

• Reflected XSS, where the malicious input originates from the victim's request.

• DOM-based XSS, where the vulnerability is in the client-side code rather than the server-side code.

• All of these attacks are performed in different ways but have the same effect if they succeed.

• The most important way of preventing XSS attacks is to perform secure input handling.

• Most of the time, encoding should be performed whenever user input is included in a page.

• In some cases, encoding has to be replaced by or complemented with validation.

• Secure input handling has to take into account which context of a page the user input is inserted into.

• To prevent all types of XSS attacks, secure input handling has to be performed in both client-side and server-side code.

• Content Security Policy provides an additional layer of defense for when secure input handling fails.

It should be noted that there is overlap in the terminology currently used to describe XSS: a DOM-based XSS attack is also either persistent or reflected at the same time; it's not a separate type of attack. There is no widely accepted terminology that covers all types of XSS without overlap. Regardless of the terminology used to describe XSS, however, the most important thing to identify about any given attack is where the malicious input comes from and where the vulnerability is located.

• How to implement whitelisting securely (July 9th, 2016)

http://excess-xss.com/