websocket-security

A security-testing guide for WebSocket-based applications such as real-time channels, chat, notifications, and WS-backed APIs, intended strictly for authorized assessments. It starts with what to watch for in proxy or raw traffic: the client upgrade headers (Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Key, Version, and Protocol) and the server's 101 Switching Protocols response with Sec-WebSocket-Accept, plus a tip to filter Burp or DevTools for 101 and Upgrade: websocket.

The centerpiece is cross-site WebSocket hijacking (CSWSH), the WebSocket analogue of CSRF over a persistent bidirectional channel. It explains the precondition (the server does not validate Origin and the victim has an active cookie-based session), provides a proof-of-concept attacker page, and walks through step-by-step exploitation: confirming no Origin check by tampering the handshake Origin in Burp, crafting an attacker page that connects as the victim, and understanding cookie behavior (SameSite=None cookies are sent, while Lax and Strict are not, since a WebSocket is not a top-level navigation). It shows that a successful hijack lets an attacker both read sensitive data and write actions as the victim. A later section covers WebSocket smuggling, using the upgrade to slip past reverse-proxy restrictions and tunnel raw HTTP once the proxy stops inspecting the connection.

Tooling bridges are provided for wsrepl (with auth plugins to reproduce cookies and headers), ws-harness (to bridge a WebSocket to HTTP so tools like sqlmap can test it), and the Burp extensions SocketSleuth and WebSocket Turbo Intruder. A common-vulnerabilities table flags missing Origin validation, auth tokens in the URL (log and Referer leakage), missing rate limiting, cleartext ws:// instead of wss://, and injection in message bodies. A six-step decision tree ties it together: identify endpoint, review handshake, test session binding with another user's cookie jar, test CSWSH, fuzz message semantics for injection, and check transport security. It cross-loads the api-sec skill because WebSocket routes often share authentication, authorization, and IDOR models with the REST APIs behind them.