# XSS (Cross Site Scripting)
/
**Bug bounty tip**: **sign up** for **Intigriti**, a premium **bug bounty platform created by hackers, for hackers**! Join us at [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) today, and start earning bounties up to **$100,000**!
{% embed url="https://go.intigriti.com/hacktricks" %}
## 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)}` ``
* **Unicode encode** works to write **valid javascript code**:
```javascript
\u{61}lert(1)
\u0061lert(1)
\u{0061}lert(1)
```
#### Javascript Hoisting
Javascript Hoisting references the opportunity to **declare functions, variables or classes after they are used**.
Therefore if you have scenarios where you can **Inject JS code after an undeclared object** is used, you could **fix the syntax** by declaring it (so your code gets executed instead of throwing an error):
```javascript
// The function vulnerableFunction is not defined
vulnerableFunction('test', '');
// You can define it in your injection to execute JS
//Payload1: param='-alert(1)-'')%3b+function+vulnerableFunction(a,b){return+1}%3b
'-alert(1)-''); function vulnerableFunction(a,b){return 1};
//Payload2: param=test')%3bfunction+vulnerableFunction(a,b){return+1}%3balert(1)
test'); function vulnerableFunction(a,b){ return 1 };alert(1)
```
```javascript
// If a variable is not defined, you could define it in the injection
// In the following example var a is not defined
function myFunction(a,b){
return 1
};
myFunction(a, '')
//Payload: param=test')%3b+var+a+%3d+1%3b+alert(1)%3b
test'); var a = 1; alert(1);
```
```javascript
// If an undeclared class is used, you cannot declare it AFTER being used
var variable = new unexploitableClass();
// But you can actually declare it as a function, being able to fix the syntax with something like:
function unexploitableClass() {
return 1;
}
alert(1);
```
```javascript
// Properties are not hoisted
// So the following examples where the 'cookie' attribute doesn´t exist
// cannot be fixed if you can only inject after that code:
test.cookie('leo','INJECTION')
test['cookie','injection']
```
For more info about Javascript Hoisting check: [https://jlajara.gitlab.io/Javascript\_Hoisting\_in\_XSS\_Scenarios](https://jlajara.gitlab.io/Javascript\_Hoisting\_in\_XSS\_Scenarios)
### Javascript Function
Several web pages have endpoints that **accept as parameter the name of the function to execute**. A common example to see in the wild is something like: `?callback=callbackFunc`.
A good way to find out if something given directly by the user is trying to be executed is **modifying the param value** (for example to 'Vulnerable') and looking in the console for errors like:
![](<../../.gitbook/assets/image (651) (2).png>)
In case it's vulnerable, you could be able to **trigger an alert** just doing sending the value: **`?callback=alert(1)`**. However, it' very common that this endpoints will **validate the content** to only allow letters, numbers, dots and underscores (**`[\w\._]`**).
However, even with that limitation it's still possible to perform some actions. This is because you can use that valid chars to **access any element in the DOM**:
![](<../../.gitbook/assets/image (662).png>)
Some useful functions for this:
```
firstElementChild
lastElementChild
nextElementSibiling
lastElementSibiling
parentElement
```
You can also try to **trigger Javascript functions** directly: `obj.sales.delOrders`.
However, usually the endpoints executing the indicated function are endpoints without much interesting DOM, **other pages in the same origin** will have a **more interesting DOM** to perform more actions.
Therefore, in order to **abuse this vulnerability in a different DOM** the **Same Origin Method Execution (SOME)** exploitation was developed:
{% content-ref url="some-same-origin-method-execution.md" %}
[some-same-origin-method-execution.md](some-same-origin-method-execution.md)
{% endcontent-ref %}
### 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.
{% content-ref url="dom-xss.md" %}
[dom-xss.md](dom-xss.md)
{% endcontent-ref %}
### **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**:
{% content-ref url="server-side-xss-dynamic-pdf.md" %}
[server-side-xss-dynamic-pdf.md](server-side-xss-dynamic-pdf.md)
{% endcontent-ref %}
{% content-ref url="../../network-services-pentesting/pentesting-web/xss-to-rce-electron-desktop-apps/" %}
[xss-to-rce-electron-desktop-apps](../../network-services-pentesting/pentesting-web/xss-to-rce-electron-desktop-apps/)
{% endcontent-ref %}
## 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