attack-surface-xss（攻击面 xss）

XSS Attack Surface Reconnaissance

Map the XSS attack surface of a target URL. Analyze security headers, client-side frameworks, JavaScript patterns, and DOM structure to identify what makes XSS possible, easier, or harder.

This skill does NOT inject payloads or test for XSS. It performs passive observation only (HTTP requests + source analysis). For active XSS testing, use /xss-finder.

Target: $ARGUMENTS (URL to analyze)

When to Use This Skill

• Before running /xss-finder — understand what defenses exist
• Scoping an XSS engagement — identify highest-value test targets
• Evaluating a site's XSS posture without active testing
• Mapping client-side technology stack for exploit development
• Identifying which XSS classes (reflected, stored, DOM) are most likely

Core Capabilities

Workflow

Phase 1: Fetch Target

Retrieve response headers and page content from $ARGUMENTS:

# Response headers (follow redirects)
curl -sI -L "$URL"

# Full page body (HTML + inline JS)
curl -sL "$URL" -o /tmp/xss-recon-body.html

Use WebFetch as fallback for JavaScript-rendered content (SPAs that return minimal HTML).

Extract script references:

1. Parse all <script> tags — capture both inline content and external src URLs
2. Fetch external JS files from same-origin and known CDNs (jsdelivr, cdnjs, unpkg, googleapis)
3. Cap at 20 external files to avoid excessive fetching
4. Store fetched JS content for Phase 4 analysis

Record metadata:

• Final URL after redirects (HTTP → HTTPS upgrade?)
• Response status code
• Server header value
• Number of redirects

Phase 2: Security Headers Assessment

Check each header and rate its XSS impact:

CSP quick assessment (inline):

• Missing CSP → flag as critical gap, all inline injection viable
• unsafe-inline in script-src → inline script injection works directly
• unsafe-eval → eval-based payloads viable
• Wildcard * or data: in script-src → script loading from any origin
• Known bypass CDNs allowlisted (googleapis, cdnjs, jsdelivr, unpkg) → JSONP/Angular bypasses
• strict-dynamic present → script gadget focus, not direct injection
• Trusted Types → DOM sink restrictions active

For deep CSP analysis, recommend running /content-security-policy $URL.

Cookie assessment:

• Missing HttpOnly → document.cookie exfiltration works
• Missing Secure → network MITM can steal cookies
• Missing SameSite → CSRF + XSS chaining viable
• All flags present → cookie theft blocked, pivot to DOM-based exfiltration

Phase 3: Framework & Library Detection

Detect client-side stack from page source, script content, and global objects.

Frameworks — detection signatures:

Security libraries — detect sanitizers:

Vulnerable library detection — extract versions from filenames and CDN URLs:

For each detected library: report version, known XSS-relevant CVEs, and specific exploitation notes.

Phase 4: JavaScript Pattern Analysis

Analyze inline scripts and fetched JS files for dangerous patterns.

DOM XSS Sinks (code that writes to DOM unsafely):

DOM XSS Sources (where attacker input enters):

Source-to-sink tracing (static approximation): For each detected source, trace whether it flows into a sink without sanitization. Flag direct connections (e.g., el.innerHTML = location.hash). Note: full taint analysis requires browser DevTools or dynamic instrumentation — this is a best-effort static scan.

Dangerous constructs:

Phase 5: DOM & HTML Analysis

Analyze page structure for XSS-relevant features.

Input vectors:

• Enumerate all <input>, <textarea>, <select> elements (visible + hidden)
• Record name, type, id, maxlength, pattern attributes
• Map forms to their action URLs and method (GET/POST)
• Flag hidden fields — often unsanitized server-side (reference xss-finder hidden field methodology)
• Flag file upload forms — SVG upload → stored XSS potential

URL parameter reflection test: For each URL parameter in $ARGUMENTS, check if value appears in response body. If reflected, note the reflection context (HTML body, attribute, script, comment).

Meta tags:

Embedding elements:

• <iframe> — sandboxed? Is src user-controllable?
• <object>, <embed> — plugin execution vectors
• Inline <svg> — enables advanced XSS vectors (onbegin, SMIL <animate>)
• <math> — MathML namespace confusion for mXSS (reference mutation-xss anti-pattern)

Inline event handlers: Count existing inline event handlers (onclick, onerror, onload, etc.) in page source. High count indicates the framework does not prohibit inline handlers — weak or absent CSP likely.

Third-party embeds:

• Google Tag Manager (gtm.js) — tag injection surface
• Analytics scripts (Google Analytics, Mixpanel, Segment) — config manipulation
• Ad network scripts — additional injection surface
• Social widgets — cross-origin messaging

Phase 6: Report Generation

Generate a structured report organized for ethical hacker workflow:

# XSS Attack Surface Report

**Target:** {URL}
**Date:** {date}
**Overall XSS Resistance:** {Strong | Moderate | Weak | Minimal}

## Executive Summary
{2-3 sentences: key findings, biggest weaknesses, recommended testing focus}

## Security Headers

| Header | Value | XSS Impact | Assessment |
|--------|-------|------------|------------|
| CSP | {value or MISSING} | {impact} | {Strong/Weak/Missing} |
| X-Content-Type-Options | {value or MISSING} | {impact} | {OK/Missing} |
| Set-Cookie | {flags or MISSING} | {impact} | {assessment} |
| ... | | | |

**Hacker Notes:** {Specific header weaknesses — e.g. "CSP has unsafe-inline, inline
script injection works directly" or "No HttpOnly on session cookie, document.cookie
exfiltration viable"}

## Technology Stack

| Component | Version | XSS Relevance |
|-----------|---------|---------------|
| {library} | {version} | {specific CVE or known bypass} |

**Hacker Notes:** {Which libraries have known bypasses, specific payloads to try}

## Dangerous JavaScript Patterns

### DOM XSS Sinks Found
| Sink | Location | Source Connected | Risk |
|------|----------|-----------------|------|
| innerHTML | inline script line 42 | location.hash | High — direct DOM XSS |
| $.html() | app.js:156 | AJAX response | Medium — depends on server sanitization |

### DOM XSS Sources Found
| Source | Handler | Origin Check | Risk |
|--------|---------|--------------|------|
| postMessage | addEventListener line 88 | No | High — any origin can inject |
| location.hash | hashchange handler | N/A | Medium — client-only input |

### Dangerous Constructs
{DOM clobbering targets, prototype pollution gadgets, JSONP endpoints, relative paths}

**Hacker Notes:** {Specific source→sink chains to investigate, bypass techniques from
xss-finder 5-Rotor methodology}

## Input Vectors

| Input | Type | Reflected | Hidden | Notes |
|-------|------|-----------|--------|-------|
| q | text | Yes | No | Search param reflected in <h1> |
| token | hidden | No | Yes | Likely unsanitized — test stored XSS |

**Hacker Notes:** {Which inputs to fuzz first, client-side restrictions to bypass}

## Best Practices Assessment

| Practice | Status | Hacker Implication |
|----------|--------|--------------------|
| CSP with nonce/hash | {Present/Missing} | {implication for inline injection} |
| HttpOnly cookies | {Present/Missing} | {cookie theft feasibility} |
| DOMPurify/sanitizer | {Present/Missing (version)} | {mXSS bypass options} |
| Trusted Types | {Present/Missing} | {sink restriction status} |
| Subresource Integrity | {Present/Missing} | {CDN MITM feasibility} |
| Meta charset | {Present/Missing} | {charset-based XSS feasibility} |

## Attack Vectors Summary

### High Priority (Test First)
1. {Most promising vector with technique reference}
2. {Second most promising}
3. {Third}

### Medium Priority
1. {Vector with conditional exploitability}
2. ...

### Low Priority (Hardened)
1. {Defended vector — explain what makes it hard}
2. ...

## Recommended Next Steps
1. Run `/xss-finder $URL` for automated payload testing on identified vectors
2. Run `/content-security-policy $URL` for deep CSP analysis
3. {Specific manual tests based on findings — e.g. "Test postMessage handler at
   line 88 with origin-less messages", "Fuzz hidden field 'token' for stored XSS"}

Overall XSS Resistance rating:

• Strong — CSP with nonce + Trusted Types + sanitizer + HttpOnly cookies + no dangerous sinks
• Moderate — CSP present but with gaps (e.g. unsafe-inline) OR sanitizer present but outdated
• Weak — Missing CSP or CSP with wildcards, dangerous sinks present, no sanitizer
• Minimal — No CSP, no sanitizer, dangerous sinks connected to sources, no HttpOnly

Each finding must reference specific exploitation techniques. Link to xss-finder 5-Rotor methodology where relevant (context detection, bypass cascades, encoding techniques).

Implementation Steps

1. Validate $ARGUMENTS is a URL (starts with http:// or https://)
2. Fetch headers with curl -sI -L; fetch body with curl -sL
3. Fall back to WebFetch if body is minimal (SPA detection)
4. Extract and fetch external script files (same-origin + CDNs, max 20)
5. Assess security headers per Phase 2 table
6. Detect frameworks and libraries; extract versions from filenames/CDN URLs
7. Cross-reference versions against known vulnerable ranges
8. Scan inline + external JS for DOM XSS sinks and sources
9. Trace source→sink connections (static approximation)
10. Enumerate input elements, forms, hidden fields
11. Test URL parameter reflection in response body
12. Check meta tags, embedding elements, inline event handler count
13. Calculate overall XSS resistance rating
14. Generate report with Hacker Notes per section

Quality Checklist

Before finalizing:

• All 6 phases executed (Fetch, Headers, Frameworks, JavaScript, DOM, Report)
• Security headers table complete — every header checked or marked MISSING
• Framework/library versions extracted where detectable
• Vulnerable library versions cross-referenced with specific CVEs
• DOM XSS sinks and sources enumerated from actual page content
• Source→sink connections flagged where statically traceable
• Input vectors include hidden fields
• URL parameter reflection tested
• Overall XSS Resistance rating justified by findings
• Hacker Notes in every report section with actionable exploitation guidance
• Attack Vectors Summary prioritized by exploitability
• Next Steps reference /xss-finder and /content-security-policy
• No active exploitation performed — reconnaissance only

Example Usage

Single URL reconnaissance:

/xss-recon https://example.com/search?q=test

Application homepage:

/xss-surface https://app.example.com

Pre-engagement scoping:

/xss-attack-surface https://target.com/login

References

• OWASP Testing Guide: XSS
• OWASP DOM-Based XSS Prevention
• PortSwigger: XSS Cheat Sheet
• CWE-79: Improper Neutralization of Input During Web Page Generation
• MDN: Content-Security-Policy
• Gareth Heyes: JavaScript for Hackers
• Retire.js: Known Vulnerable Libraries
• Snyk Vulnerability Database

Related Skills

• Content Security Policy: Deep CSP analysis — delegate with /content-security-policy $URL
• XSS Finder: Active XSS testing — run after reconnaissance with /xss-finder $URL
• Cross-Site Scripting (XSS): Reflected, stored, and DOM XSS patterns
• DOM Clobbering: Global variable clobbering detection
• Mutation XSS: Sanitizer bypass via mXSS
• Missing Security Headers: Header assessment baseline