--- name: hunt-websocket description: Hunt WebSocket vulnerabilities category: security risk: offensive source: https://github.com/elementalsouls/Claude-BugHunter source_repo: elementalsouls/Claude-BugHunter source_type: community date_added: '2026-09-20' license: MIT license_source: https://github.com/elementalsouls/Claude-BugHunter/blob/main/LICENSE compatibility: Requires explicit written authorization for a target scope plus the relevant testing tools for this technique. Docs-only; helper scripts and commands not bundled. sources: hackerone_public, portswigger_research, cve report_count: 0 --- > **⚠️ AUTHORIZED USE ONLY** > This skill is for educational purposes or authorized security assessments only. > You must have explicit, written permission from the system owner before using this tool. > Misuse of this tool is illegal and strictly prohibited. > **Mandatory confirmation gate** > Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target: > 1. Ask the user to state the exact target URL, IP, account, or resource. > 2. Ask the user to confirm written authorization and the permitted scope. > 3. Show the exact command(s) and explain their expected effect. > 4. Wait for explicit confirmation in the current conversation. > > Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab. # HUNT-WEBSOCKET — WebSocket Security ## When to Use Review WebSocket handshake, message authorization and protocol state in an explicitly authorized application or isolated lab. No runtime, scanner, report corpus or Burp MCP tool is bundled; report_count0 means no bundled reports, not an empirical finding count. Upstream attribution is retained. ## Mandatory confirmation gate Before any endpoint probe, connection, authentication attempt, message, replay, browser PoC, callback or configuration change, obtain the exact target/accounts, written owner permission, allowed techniques and request/time/connection/cost limits. Present the exact operation and expected effects and wait for explicit confirmation in this conversation. Without it, inspect supplied source/captures only. Use two owner-controlled synthetic accounts/tenants and a disposable canary object. Do not read real victim data, delete users, place real trades/payments, steal tokens, capture other users' requests or send payloads to third parties. A permitted read request can still create server state or load. Stop on unexpected sensitive data or scope. ## 1. Inventory and transport evidence Read supplied client/server code or approved captures for exact endpoints, path, protocol, authentication, Origin, cookies, subprotocols and frame schemas. Restrict any discovery to the named scope; no port scans or broad crawling by default. Raw URLs/frames can include tokens and personal content, so store privately and redact reports. A standards-style WebSocket upgrade uses GET; curl -I sends HEAD and cannot be relied on as a normal handshake test. HTTP101 means a protocol upgrade, not authenticated data access. Engine.IO EIO=4 identifies a protocol version, not the exact Socket.IO package release. Resolve installed versions from manifests/lockfiles and verify actual advisories; a recognizable endpoint alone does not prove a CVE. ## 2. Cross-site WebSocket hijacking Trace whether a browser on an untrusted origin can automatically supply the target authentication and perform a protected action or receive a synthetic private canary. Cookie SameSite/Secure policy, browser behavior, origin validation and application-level authentication all affect this. A token's presence does not automatically prevent hijacking: verify unpredictability, binding, validation, exposure and whether an attacker can obtain/reuse it. A token in a URL may leak in logs. A CLI client can set Origin/Cookie headers, so it cannot alone prove the real browser threat model. Use an authorized owner-lab browser test with the target's actual cookie/session policy. Compare a permitted origin with one owner-controlled foreign origin and an unauthenticated control. Record only the canary identifier or a pass/fail boundary observation, not frame contents or secrets. No OAST exfiltration is required; an approved local browser recording/server log can prove receipt. Callback source IP alone does not establish identity or impact. ## 3. Per-message and lifecycle authorization A connection may authenticate once, but each sensitive action/object/room needs effective authorization and schema checks. Inspect tenant ownership, server-derived prices/roles, state prerequisites, session expiry/revocation and logout behavior on existing sockets. Static permissions can be cached appropriately if revocation and resource changes are handled; redoing login on every frame is not the requirement. For the approved synthetic test, use one harmless read/subscription to an owner canary. Compare same-tenant allowed versus other-tenant denied behavior, and confirm by an independent owner-side observation. An accepted frame, success acknowledgement or optimistic echo is not proof of access or persistence. Replay tests use a nonfinancial sandbox action with explicit idempotency/freshness expectations; do not assume every signed message must be single-use. ## 4. Socket.IO, SignalR and Phoenix Use the exact protocol/client version, heartbeat and transport lifecycle. Socket.IO namespaces and application rooms are different controls; a namespace acknowledgement does not prove access to a privileged room. E.g., Engine.IO message4 wrapping Socket.IO connect0 can produce `40/admin,` for a compatible protocol, while event2 produces a42 prefix. These historical wire examples are not a complete client, do not establish authorization and do not apply unchanged to SignalR or Phoenix. Review actual join/subscribe/method handlers and obtain the canary only through the approved synthetic accounts. ## 5. Parser, proxy and resource limits Inspect bounded message size, decompression, parsing, connection count, per-principal/action rate budgets, idle timeout, backpressure and cleanup. HTTP429 is not a mandatory WebSocket throttling signal; the application may reject frames or close connections. Receiving no429 does not prove no control. Do not send hundreds of frames/second, trigger ReDoS or exhaust connections to test a checklist. Any load test needs a separate owner-approved lab budget and abort threshold. Upgrade-related smuggling depends on a specific proxy/origin disagreement. A malformed handshake response or delay alone is insufficient. Correctly framed established WebSocket traffic is not ordinarily reparsed as HTTP, but broken upgrade/tunneling components require exact implementation evidence. Investigate only in an isolated owner stack with synthetic downstream requests and no shared users/caches. Do not poison public caches or capture another user's traffic as a proof requirement. ## Example: two synthetic tenants ```text Scope: disposable owner lab, two test tenantsA/B, one canary notification. Allowed operation: one subscription attempt under each explicitly approved identity. Control: tenantA receives only its own canary; tenantB must not receive it. Evidence: actual browser-origin/session conditions, request/job identifier and redacted result. Status: record observed allowed/denied/unknown; no live result is asserted here. ``` ## Reporting and remediation Report immutable scope/versions, actual authentication model, browser/protocol preconditions, source-to-action trace, synthetic control and observed boundary, redacted evidence and uncertainty. Severity depends on actual privileges and impact; token strings, HTTP101, namespace ack and an automatic Critical label are not impact proof. Propose exact Origin allowlisting where appropriate, session/token checks, per-resource authorization, schema/size validation, revocation, idempotency, budgets and logging redaction. Origin is useful against browser cross-site attacks but is forgeable by nonbrowser clients and never replaces authentication. Retest the same fixture against the exact fixed head. ## Limitations No browser, target, provider, tool or historical case has been tested here. Verify current protocol and vendor documentation for the pinned versions. External reporting, hosting a PoC, installing tools and target changes require actual user authority. Optional companion skill names are not bundled runtime dependencies or evidence.