shield_lock
JinDaGe
← Back to skills
extension
Category: Development & EngineeringNo API key required

pentest-xss

Security assessment skill for Cross-Site Scripting (XSS) vulnerabilities. Use when investigating input sanitization, reflected, stored, DOM, or blind XSS. Focuses on discovery, exploitation, and payload optimization. Do not use for generic network recon or non-web injection types.

personAuthor: jakexiaohubgithub
open_in_newRepositorydownloadDownload package

Cross-Site Scripting Assessment

Purpose

Find and validate XSS by mapping controllable sources to browser execution contexts, proving execution safely, and handing off callback or parser work when needed.

Use When

  • The owner phase is reflected, stored, DOM, or blind XSS.
  • The task needs HTML, attribute, JavaScript, URL, CSS, template, or browser-sink context analysis.
  • CSP, WAF, sanitizer, encoding, or client-side source-to-sink behavior is central.

Inputs

  • Target URL, parameter, header, cookie, body field, DOM source, or captured request.
  • Scope and target allowlist.
  • Authenticated session or test account when stored or admin-viewed surfaces are involved.
  • Optional CSP, sanitizer behavior, client-side source, proxy traffic, and OOB listener details.

Workflow

  1. Confirm scope, identity context, and safe test target before injecting payloads.
  2. Enumerate controllable sources: URL parameters, path segments, headers, cookies, JSON/XML/form fields, uploads, and DOM sources such as location, postMessage, storage, or referrer.
  3. Identify reflection or sink context: HTML text, tag, attribute, script block, URL, CSS, template, markdown, rich text, or dangerous DOM sink such as innerHTML, outerHTML, insertAdjacentHTML, document.write, eval, or framework escape hatches.
  4. Start with inert markers and context breakers before executable payloads.
  5. Use minimal payloads that prove execution without stealing tokens, redirecting users, or disrupting production state.
  6. For stored or blind paths, use unique tokens, timestamps, and a controlled callback endpoint.
  7. Compare controls: benign marker, escaped marker, alternate context, alternate role/viewer, and expected deny path.
  8. Stop once capability is proven and preserve exact request, response, rendered context, browser evidence, and timestamps.

Verification Gate

  • Do not report XSS from reflection alone; prove browser execution or a clear source-to-sink path with executable context.
  • For blind XSS, require deterministic OOB correlation by token, path or subdomain, timestamp, and control outcome.
  • For DOM XSS, identify the controllable source, transformation path, sink, and required user/browser action.
  • For CSP or WAF bypass claims, show the relevant policy/filter behavior and a working control comparison.

Situational Awareness

  • Low-volume manual testing comes before broad match-and-replace automation.
  • Use automation only against allowlisted hosts and parameters, with unique traceable markers and stop conditions.
  • Pivot to parser/encoding work only when the payload behavior changes across content type, browser, sanitizer, or request parser.

Handoff Criteria

  • Hand off to pentest-outbound-interaction-oob-detection for blind XSS callback setup, tokening, monitoring, and correlation.
  • Hand off to pentest-input-protocol-manipulation for parser differentials, encoding confusion, content-type changes, or request mutation.
  • Hand off to pentest-evidence-structuring-report-synthesis once execution and impact evidence are complete.

Output

  • XSS type and context.
  • Source, transformation path, sink, and required preconditions.
  • Minimal proof payload or marker, redacted if needed.
  • Browser or callback evidence with controls.
  • Impact statement tied to reachable user role and data/action exposure.
  • Remediation guidance for output encoding, sanitizer configuration, CSP, framework escape hatches, or sink replacement.