intro to xss
Tags: hacking
Published: 2020-05-07 18:12:33


### introduction to cross-site scripting(xss), basics, methodology, dangers & mitigations

*This was written as part of my application to SecAppDev 2020 which got cancelled due to the current pandemic*

## <center>What is XSS?</center>

Cross-site scripting or `XSS`, is a vulnerability which allows an attacker to inject & execute malicious code, usually `javascript`, into an application under the victim's context, it is listed under the [OWASP Top 10 Vulnerabilities](https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf) as #7, some popular types of `XSS` are:

- `reflected`
  - The application is reflecting some unsanitized data that it received through a parameter directly in the response
  - Attack requires the victim to click on a link. i.e `https://realsite.com/?search=<img src=x onerror=alert(document.cookie)`
  - When the victim clicks the link, the vulnerable application will execute the payload in the victim's context because the value passed to the `search` param is being echoed back in the body of the response unsanitized, in the example above the application will try to render an image that does not exist, and thanks to `html` I can execute `JavaScript` by using the `onerror` event handler, since `JavaScript` has access to the `document.cookie` we can put it in an `alert` prompt for testing.

<hr>

- `stored`
  - The unsanitized data can be saved somewhere in the application's database, for example in an application that contains a profile with an editable bio section, if the user's input is not being properly sanitized an attacker might be able to submit `"><script>prompt</script>` in their "bio" and save it, this specific string if left unsanitzed will execute `JavaScript` each time the page is visited.
  - This type of `xss` is for the most part considered of higher severity than `reflected xss` since `stored xss` does **not** need user interaction to execute, the victim simply has to visit the page for the malicious code to run.

<hr>

- `dom`
  - `DOM XSS` is a bit different, the attack takes advantage of client side `JavaScript` that uses unsanitized user input,might be possible to execute `JavaScript` in the victim's context
  - `https://evil.com/#pirateducky"><script>alert(1)</script>`
  - If the application is using the `URI fragment` to pass down data to the application, our payload might be able to achieve execution, in the example below the `URI fragment` is being used somewhere in code which then gets written to the `DOM` and since this is a script it will execute the `alert` prompt. 

## <center>Methodology</center>

Finding `XSS` requires a good understanding on how an application responds to unsafe input. Testing all inputs is essential to understanding how the application behaves, sometimes developers forget to sanitize all `API` endpoints so always look at an application well and gather as much information as possible, check `JavaScript` files and see if you can find where user input is being passed down to the application(sinks). When testing for `xss`, I usually try to see if I can inject the following payload first:

```html
"'/><h1>test</h1
// this payload will close the tag before it and start a new tag
```

This will answer some assumptions about the application I am testing:
1. Is the application sanitizing dangerous characters(/,<,>,",')?
2. Does the application render the payload?

The process can be done regardless of the type of `xss` I am looking for, the main takeaway is seeing what is being echoed back in the body of the response, if I can get the application to render the `html` I submitted the next thing to check is if I can execute `JavaScript`, some ways of doing this are:

```html
"><script>alert(1)</script> // straight to point, executes using script tag
"><img src=x onerror=prompt /> // a bit more covert, executes JavaScript using error handlers
<body onload=alert(1)/> // executes using event handlers

```

<hr>
 
## <center>Impact</center>

Evaluating the impact of `xss` like other vulnerabilities comes down to where the vulnerability is in the application and how hard it is to fire an attack. `Reflected xss` is typically lower than `stored xss` since the latter does not require any interaction, while `reflected xss` needs the victim to click a link sent by an attacker - this might be done using phishing techniques. 

- Account Hijacking
  - If the attacker is able to steal the victim's cookies the attacker might be able to hijack the session by impersonating the victim
- Defacement
  - If the attacker can inject `JavaScript` changing the `DOM` is possible, also if just `html` injection is achieved this also applies
- Information Disclosure
  - If sensitive information is stored in clientside `JavaScript` it can be exfiltrated a number of ways


## <center>Mitigation</center>

If we only break stuff it means we are only doing half of our job, we also have to provide ways to mitigate the vulnerability.

To mitigate `xss` developers should:
  - Identify all places user provided input is used in the application
  - Escape characters that will allow injection such as `<`,`>`,`/`,`"`,`'`
  - Output should be encoded everywhere user input is displayed
  - Filter and validate user input as strictly as possible
  - Use `HTTP` headers to your advantage including `Content Secure Policy` to restrict access to sources such as external scripts