> For the complete documentation index, see [llms.txt](https://mainekhacker-1.gitbook.io/mainekhacker/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mainekhacker-1.gitbook.io/mainekhacker/web-pentesting/xss-cross-side-scripting.md).

# XSS (Cross-Side Scripting)

### DOM-Based XSS Explained

DOM-based XSS occurs when JavaScript takes data from an attacker-controllable source (like the URL) and passes it to a sink that executes code dynamically (like `eval()` or `innerHTML`).

***

### How It Works

The attack requires two components:

1. Source: Where attacker-controlled data enters. The most common source is the URL (`window.location`), accessed through query strings, fragments, or paths.
2. Sink: Where dangerous code execution happens. Examples include:
   * `document.write()`
   * `innerHTML`
   * `eval()`
   * Event handlers like `onerror` or `onload`

An attacker constructs a malicious link with a payload in the URL, which the page's JavaScript automatically processes and executes without proper validation.

***

### Testing Methods

#### For HTML Sinks

* Insert a random string into the source and use browser developer tools (e.g., Chrome's inspector) to locate where it appears in the DOM
* Inspect the context (is it in an attribute? a tag?) and refine your payload accordingly
* Note: "View source" won't work for DOM XSS; you must inspect the live DOM

#### For JavaScript Execution Sinks

* Use the JavaScript debugger to find where the source is referenced in code
* Add breakpoints and trace how data flows through variables to the sink
* Inspect variable values to determine if you can exploit them

***

### Common Vulnerable Patterns

| Sink                  | Example Payload                                   | Notes                                             |
| --------------------- | ------------------------------------------------- | ------------------------------------------------- |
| `document.write()`    | `<script>alert(1)</script>`                       | Works with script elements                        |
| `innerHTML`           | `<img src=1 onerror=alert(1)>`                    | Script tags don't execute; use img/iframe instead |
| jQuery `attr()`       | `?returnUrl=javascript:alert(1)`                  | Manipulates element attributes                    |
| jQuery `$()` selector | `#<img src=1 onerror=alert(1)>`                   | Injects into hash-based selectors                 |
| AngularJS `ng-app`    | `{{constructor.prototype.isPrototypeOf(Object)}}` | Executes JavaScript in curly braces               |

***

### Reflected vs. Stored DOM XSS

Reflected DOM XSS: The server echoes URL parameters into the response, and JavaScript then processes this data unsafely. The vulnerability chain: request → server reflection → DOM sink.

Stored DOM XSS: The server stores attacker data and includes it in later responses. A script then processes the stored data unsafely, creating a persistent vulnerability.

***

### Prevention

Avoid passing user-controlled data to dangerous sinks. Use safe alternatives like `textContent` instead of `innerHTML`, validate and sanitize all input, and use modern frameworks with built-in protections.

## **Exploiting cross-site scripting to steal cookies;**

Stealing cookies is a traditional way to exploit XSS. Most web applications use cookies for session handling. You can exploit cross-site scripting vulnerabilities to send the victim's cookies to your own domain, then manually inject the cookies into the browser and impersonate the victim.

### **Content security policy:**

### What is CSP (content security policy)?

CSP is a browser security mechanism that aims to mitigate\
XSS and some other attacks. It works by restricting the resources (such\
as scripts and images) that a page can load and restricting whether a\
page can be framed by other pages.

To enable CSP, a response needs to include an HTTP response header called `Content-Security-Policy` with a value containing the policy. The policy itself consists of one or more directives, separated by semicolons.

**Bypassing CSP with policy injection:**

Most likely in a `report-uri` directive. If the site reflects a parameter that you can control, you can inject a semicolon to add your own CSP directives.this new directive allows you to [overwrite existing `script-src` directives](https://portswigger.net/research/bypassing-csp-with-policy-injection).

**Protecting against clickjacking using CSP:**

The following directive will only allow the page to be framed by other pages from the same origin:

```
frame-ancestors 'self'
```

The following directive will prevent framing altogether:

```
frame-ancestors 'none' frame-ancestors 'self' <https://normal-website.com> https://*.robust-website.com
```