# XSS \(Cross Site Scripting\)
## Methodology
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 bypass protections?
4. 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).
5. 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 ``** tags of a HTML page, inside a **`.js`**file or inside an attribute using **`javascript:`** protocol:
* If reflected between **``** tags, even if your input if inside any kind of quotes, you can try to inject `` 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 `` 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.
{% page-ref page="dom-xss.md" %}
### **Universal XSS**
These kind of XSS can be found **anywhere**. They not depend just on the client exploitation of a web application but on **any** **context**. These kind of **arbitrary JavaScript execution** can even be abuse to obtain **RCE**, **read** **arbitrary** **files** in clients and servers, and more.
Some **examples**:
{% page-ref page="server-side-xss-dynamic-pdf.md" %}
{% page-ref page="../../pentesting/pentesting-web/xss-to-rce-electron-desktop-apps.md" %}
## WAF bypass encoding image
![from https://twitter.com/hackerscrolls/status/1273254212546281473?s=21](../../.gitbook/assets/eaubb2ex0aerank.jpg)
## Injecting inside raw HTML
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