技能介绍

要解决的具体问题

WebSocket 把一次 HTTP 请求升级为长连接，之后的双向帧、会话 Cookie、代理转发规则和普通 REST 并不完全一致。团队常把认证、授权、速率限制只放在 HTTP API 上，结果 WebSocket 路由出现跨站 WebSocket 劫持（CSWSH）、Origin 校验缺失、令牌写进 URL、明文 ws://、消息体注入，甚至通过 upgrade 绕过反向代理。Socket.IO 的命名空间、事件名、ack 回调和 HTTP 长轮询回退，还会带来额外边界。

技能如何工作

这个技能按可审计的路径组织测试，而不是泛泛扫一遍。

协议基础：检查 Upgrade: websocket、Connection: Upgrade、Sec-WebSocket-Key / Sec-WebSocket-Accept 和 Sec-WebSocket-Version: 13；确认 101 Switching Protocols 后进入帧层。
CSWSH 验证：先确认握手是否校验 Origin，再看受害者是否有活动会话，以及 Cookie 的 SameSite 策略。可用本地 HTML 页面模拟攻击者来源，验证服务端是否拒绝错误 Origin 或改用非 Cookie 密钥。
工具链桥接：wsrepl 复现浏览器 Cookie、Header 和令牌刷新；ws-harness 把 WebSocket 桥接成 HTTP，便于复用注入工具；Burp Suite 中用 SocketSleuth 查看和修改流量，用 WebSocket Turbo Intruder 做高频或脚本化模糊测试。
消息与传输审查：关注消息体里的 SQLi、命令注入、存储型 XSS；识别 ws://、URL 中的 token=、缺失速率限制；必要时用 wsdump、protobuf-inspector、msgpack-tools、Wireshark 分析二进制帧。
走私与库特性：测试 upgrade 后是否绕过 Nginx、HAProxy、ALB、Cloudflare、Varnish 的限制；对 Socket.IO 检查命名空间授权、事件名注入、ack 数据泄漏和长轮询 CSRF。

适用边界与注意点

只用于已授权的测试，令牌、Cookie 和消息内容按敏感数据处理。不要把 api-sec 的结论直接套到 WebSocket：如果后端共享会话和权限模型，应交叉加载 api-sec 对齐认证与资源边界。生产环境优先 wss://，避免把认证信息放在查询串，也不要仅依赖 Cookie 而缺少 CSRF 防护。工具给出的是可观测信号，最终判定要结合业务语义、日志和代理行为。