返回 Skill 列表
extension
分类: 开发与工程无需 API Key

pentest-xss

针对跨站脚本(XSS)漏洞的安全评估技能。在调查输入清理、反射型、存储型、DOM型或盲型XSS时使用。重点在于发现、利用和优化负载。不要用于通用网络侦察或非Web注入类型。

person作者: jakexiaohubgithub

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.