# XSS (Cross Site Scripting)
If you are interested in **hacking career** and hack the unhackable - **we are hiring!** (_fluent polish written and spoken required_).
{% embed url="https://www.stmcyber.com/careers" %}
## 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/)?
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 so you can abuse scenarios where a XSS is using undeclared variables or functions.**\
**Check the following page for more info:**
{% content-ref url="js-hoisting.md" %}
[js-hoisting.md](js-hoisting.md)
{% endcontent-ref %}
### 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/electron-desktop-apps/" %}
[electron-desktop-apps](../../network-services-pentesting/pentesting-web/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:
```html