XSS (Cross-Site Scripting) Attacks & Prevention
Tags: security, cybersecurity, webdev, programming
Published: 2021-02-21 18:47:10

The original article can be read here: [AppSec Monkey - XSS](https://www.appsecmonkey.com/blog/xss). If you prefer a YouTube video, then [here](https://youtu.be/MEzqSZzJkHI).

## What are XSS vulnerabilities?
XSS (Cross-Site Scripting) vulnerabilities arise when untrusted data gets interpreted as code in a web context. They usually result from: 

1. Generating HTML unsafely (parameterizing without encoding properly).
2. Allowing users to edit HTML directly (WYSIWYG editors for example).
3. Allowing users to upload HTML/SVG files and serving those back unsafely.
4. Using JavaScript unsafely (passing untrusted data into executable functions/properties).
5. Using outdated and vulnerable JavaScript frameworks.

## How to prevent XSS vulnerabilities?
Follow these steps: 

1. Generate HTML safely using a templating engine, or use a static JavaScript frontend to avoid HTML generation altogether.
2. If you display untrusted HTML content on your website, purify it first and contain it in a sandboxed frame.
3. Serve all downloads with a proper Content-Disposition header to prevent user-supplied HTML/SVG from being rendered in your origin.
4. Don't pass untrusted data into executable JavaScript functions/properties such as `eval`, `innerHTML` or `href`.
5. Use well-known components with a good security history and keep them up to date.
6. Implement a proper CSP (Content Security Policy).

## What is untrusted data?
Before we begin let's quickly touch on this point. Untrusted data, for the sake of this article, is anything that is or could be controlled by someone or something else than your web application.

User input is one clear example. But you should also consider any data retrieved from external sources, even your database or API, as potentially dangerous and render it with proper safety measures.

A good rule of thumb is that if it's not a static resource then it's untrusted data at least on some level.


## Why are XSS vulnerabilities bad?
Being able to execute JavaScript code on a website in other people's browsers is equivalent of logging in to the hosting server and changing the HTML files for the affected users.

As such, XSS attacks effectively make the attacker logged in as the user who is attacked, with the nasty addition of being able to trick the user into giving some information (such as their password) to the attacker, or perhaps downloading and executing malware on the user's workstation.

## 1. Generate HTML safely

### A simple example

Here is a vulnerable PHP script: 
```php
echo "<p>Search results for: " . $_GET('search') . "</p>"
```

It is vulnerable because the HTML is generated unsafely, the `search` parameter is not *encoded* properly. An attacker can create a link such as the following, which would execute the attacker's JavaScript code in the victim's browser when the link is opened.

```html
https://www.example.com/?search=<script>alert("XSS")</script>
```

Results in HTML like: 
```html
<p>Search results for: <script>alert("XSS")</script></p>
```


### The importance of encoding
So how then can you safely display the value `<script>alert("XSS")</script>` in your HTML? The answer is: HTML entity encoding: 
```
 & --> &amp;
 < --> &lt;
 > --> &gt;
 " --> &quot;
 ' --> &#x27;
```

PHP has a function called `htmlspecialchars` that performs this operation. So if we change our script a little bit (This is a horrible legacy approach but it suffices now for demonstration): 

```php
echo "<p>Search results for: " . htmlspecialchars($_GET('search')) . "</p>"
```

...the resulting HTML will be safe.

```html
<p>Search results for: &lt;script&gt;alert(&quot;XSS&quot;)&lt;/script&gt;</p>
```

### Encoding contexts
HTML entity encoding is only for when you want to put something inside HTML tags or quoted HTML attributes.

If your variables go inside JavaScript variables or URL addresses, you need another encoding function for that.

And never forget to quote your HTML attributes and JavaScript variables or no encoding in the world will save you.

Also never put untrusted data, encoded or not, within HTML attributes that get registered as DOM event handlers. These are the `onClick`, `onMouseEnter` and friends.

There are quite a few things that should be accounted for and OWASP has curated a nice list of them here: 
[Cross-Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)

However, I wouldn't advise you to focus on that too much, because... are we really happy with this?

```php
echo "<p>Search results for: " . htmlspecialchars($_GET('search')) . "</p>"
```

No. That's horrible. Mixing presentation and code is so 90's.

```bash
$ rm legacy.php
```

### Template engines to the rescue
What you should do instead is have your controller method somewhere render a template with the data that you want to display. In the case of PHP, Twig is a good option. You would have `search.html.twig` with the following content: 

```twig
<p>Search results for: {{search}}</p>
```

And your `search` parameter would be automatically escaped due to the automatic encoding done by the template engine.
- [https://symfony.com/doc/current/templates.html#output-escaping](https://symfony.com/doc/current/templates.html#output-escaping)

There are good template engines for all programming languages worth their salt. Jinja for Python, Thymeleaf for Java, and so on.

### ...or just don't generate HTML at all!
Another great way not to deal with the dangers of HTML generation is not to generate HTML. You can do this by creating a static HTML/JavaScript frontend and perhaps a backend API.

## 2. Purify and sandbox untrusted content
There are scenarios where you might want to render content that you don't fully trust. Maybe you want your users to create HTML in a WYSIWYG editor, or perhaps you want to download an HTML response from a third party and display it to the user.

Whatever the use case, the solution is the same. Purify and sandbox.

### Purify
Purifying is the act of removing any dangerous parts from an HTML string. This can be done on the client-side with `DOMPurify` or on the server-side with several tools such as the OWASP `Java HTML sanitizer` for Java or Mozzila's `bleach` for Python. Just pick a well-esteemed one.

- [https://github.com/cure53/DOMPurify](https://github.com/cure53/DOMPurify)
- [https://owasp.org/www-project-java-html-sanitizer/](https://owasp.org/www-project-java-html-sanitizer/)
- [https://github.com/mozilla/bleach](https://github.com/mozilla/bleach)

### Sandbox
Purifying is a good first step but I wouldn't leave my website's security hanging on one thing like that. Especially since there is a fantastic control that we can easily use to present untrusted HTML content: sandboxed iframes!

- [https://www.w3schools.com/tags/att_iframe_sandbox.asp](https://www.w3schools.com/tags/att_iframe_sandbox.asp)

Sandboxed iframes run by default in their own *origin*, that is, if anything bad happens in the frame, it cannot access your website. Also sandboxed iframes by default prevent script execution and even links. Very useful for our purposes!

Here is an example of a non-sandboxed frame. If you run it, you should see an `alert` box with the message "evilness".

```javascript
var untrustedHtml = "<h1>test<\/h1><script>alert('evilness');<\/script>";
document.getElementById('test-frame').src = "data:" + "text/html;charset=utf-8," + escape(untrustedHtml);
```

Try it [here](https://jsfiddle.net/v9tedm5f/1)!

Here is another fiddle with the `sandbox` attribute specified. Notice that this time the script does not get executed.

```javascript
var untrustedHtml = "<h1>test<\/h1><script>alert('evilness');<\/script>";
document.getElementById('test-frame').src = "data:" + "text/html;charset=utf-8," + escape(untrustedHtml);
```

Try it [here](https://jsfiddle.net/gkw72ra4)!

Such is the magic of sandboxed frames.

## 3. Serve downloads properly
When you allow users to upload files, there is a risk that they upload a malicious HTML, SVG, etc. file that will then be downloadable from your domain. And if the download is not served properly, it might open in a web browser just like any other content on your website, and contain for example malicious JavaScript code.

You should of course prevent users from uploading anything except for whitelisted extensions and validate the file contents as well. But just to be safe, serve all downloads so, that instead of being rendered in the browser, a "save file" dialog is presented to the user.

This can be achieved via the `Content-Disposition` header.

- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)

By specifying `attachment`, you tell browsers to show the save file dialog.

```yaml
Content-Disposition: attachment; filename="filename.jpg"
```

## 4. Use JavaScript safely
Not all XSS vulnerabilities arise from unsafe HTML. Sometimes your JavaScript code can have vulnerabilities in it that cause a vulnerability.

To get such a vulnerability, all you have to do is pass untrusted data into a function or property that either executes something or changes the HTML or HREF of something.

Here are a couple of examples just so that you get the idea.

1. Passing untrusted data to jQuery `append`. This is an example of passing untrusted data to a function that writes HTML.
```javascript
var untrusted = "hey<script>alert('xss')<\/script>";
$('#content').append(untrusted);
```

Try it [here](https://jsfiddle.net/fzec0kxo/1/)!

2. Passing untrusted data to a `href` attribute. This example demonstrates that not even React applications are safe from XSS if you don't know what you are doing (click the user's homepage link to see).

```javascript
class VulnerableApp extends React.Component {
  constructor(props) {
    super(props)
    this.state = {
    	usersHomepage: "javascript:alert('xss')"
    }
  }
  
  render() {
    return (
      <div>
        <p>User's homepage: <a href={this.state.usersHomepage}>User's homepage</a></p>
      </div>
    )
  }
}

ReactDOM.render(<VulnerableApp />, document.querySelector("#app"))
```

Try it [here](https://jsfiddle.net/nLxjtmu0)!

3. Passing untrusted data to `eval`. This is an example of passing untrusted data to a function that executes something. This simple calculator will execute code if you enter values like `;alert('xss');` into one of the operands.

```javascript
function calculate() {
	var op1 = $('#operand1').val();
  var op2 = $('#operand2').val();
  var answer = eval(op1 + ' + ' + op2);
  $('#answer').text(answer);
}
```

Try it [here](jsfiddle.net/kd9tsx1w)!

There is virtually an infinite list of functions and properties that you shouldn't pass untrusted data into, so I couldn't possibly list them all here. They include things like `innerHTML`, `outerHTML`, `setTimeout` and so on, and of course, the JavaScript libraries that you use have their own, like the jQuery example above.

It's better to be safe than sorry, so check the documentation for the function/property before assigning/appending untrusted data into it.

## 5. Use well-known JavaScript libraries and keep them up to date
Don't use NPM packages with a small number of downloads, because they can have vulnerabilities and even contain purposefully malicious code. Try to use well-known libraries with a decent security record instead.

Even the best of libraries have vulnerabilities now and then, so you should keep them up to date. You can use tools such as `retire.js` and `npm audit` to scan your web application for vulnerable outdated JavaScript libraries.

- [https://retirejs.github.io/retire.js/](https://retirejs.github.io/retire.js/)
- [https://docs.npmjs.com/cli/v6/commands/npm-audit](https://docs.npmjs.com/cli/v6/commands/npm-audit)

## 6. Implement a Content Security Policy
Content Security Policy (CSP) is an amazing browser security feature that can armor your web application against XSS vulnerabilities, in the case that regardless of your best efforts to follow the guidelines in this article, you still end up with a vulnerability in your application.

- [https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)

CSP restricts your web application in what it can do in terms of e.g. loading resources and executing scripts. Like the iframe sandbox described above, CSP also restricts everything by default, and then you can start adding exceptions for the resources that you *do need*.

Here is a good policy to get started with. It prevents lots of things, but most importantly: 

1. It prevents eval and friends.
2. It prevents inline JavaScript tags.
3. It prevents loading JavaScript files from external domains.
4. It prevents `javascript:` URLs.

```yaml
Content-Security-Policy: script-src 'self'; form-action 'self'; object-src 'none';
```

So basically it would prevent all of the XSS vulnerabilities we have described so far from being meaningfully exploited. The `form-action` even prevents the attacker from inserting a fake form on the page asking e.g. the victim's password and submitting it to the attacker's server.

So what's the catch? *Your inline scripts won't work either*. For CSP to work in this simple form, you will have to refactor your code in such a way that you won't break your own rules.

1. You don't use inline scripts.
2. You don't use inline DOM event handlers (onClick, etc).
3. You don't use eval and the scripts/frameworks that you don't use it either.

This is where you start adding exceptions. If you absolutely must use a JavaScript framework that uses eval, then you will have to specify `unsafe-eval`. And if you want to load a script externally, then you will have to add that URL into the `script-src` directive.

These are not the end of the world. But please, whatever you do, do not specify `script-src unsafe-inline`, because then you will downgrade your CSP to the point where it's almost useless.

If you absolutely must have inline JavaScript tags, use CSP nonces and/or hashes to allow those specific tags. I won't go into detail about that in this article but you can read more about this approach here: 

- [https://content-security-policy.com/nonce/](https://content-security-policy.com/nonce/)
- [https://content-security-policy.com/hash/](https://content-security-policy.com/hash/)

When you are done with your policy, you can use [Google's CSP evaluator](https://csp-evaluator.withgoogle.com/) to check it.

## Bonus: Implement Strict SameSite cookies
There is one more browser security feature that you can use to harden your application against reflected XSS attacks, that is, attacks that originate through malicious links or websites. And that is strict `SameSite` cookies.

The crux of it is that you can set your session cookies with the `SameSite=Strict` attribute, and then web browsers will no longer send the user's session cookie in requests that originate from other websites, *even* if they are `GET` requests.

```yaml
Set-Cookie: SessionId=123; SameSite=Strict
```

The catch is that links to your application will break in the sense that your logged in user will actually be logged out in all tabs/windows that are opened from anywhere except for your website. But if that doesn't bother you, do take advantage of `SameSite`! At any rate you should at least use `SameSite=Lax` which protects against CSRF (Cross-Site Request Forgery) vulnerabilities.

- [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite)

## Conclusion
It is quite possible to avoid XSS vulnerabilities and as an additional layer of security mitigate them with CSP. But this requires using modern technologies, knowing what you are doing, and implementing an effective CSP header.

## Get the web security checklist spreadsheet!
[![Subscribe](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3iqd1ef4a5a0icyvvk65.jpg)](https://eepurl.com/hqAGt5)
 ☝️ [Subscribe](https://eepurl.com/hqAGt5) to AppSec Monkey's email list, get our best content delivered straight to your inbox, and <b>get our 2021 Web Application Security Checklist Spreadsheet for FREE</b> as a welcome gift!

## Don't stop here
If you like this article, check out the other application security guides we have on [AppSec Monkey](https://www.appsecmonkey.com/) as well.

Thanks for reading.