【渗透记录】某第三方支付对接平台的WebSocket劫持

一、故事背景

这次对某第三方支付对接平台进行安全测试。目标系统为多个棋牌平台提供代收代付的支付通道系统，接口与资金流水密集。游戏平台的实时通信通常走 WebSocket，而 WebSocket 的鉴权往往被开发者忽略。我在拿到授权后，重点测试了 WebSocket 连接的鉴权机制和跨站劫持风险。

二、信息收集

信息收集阶段，我抓取了游戏客户端的 WebSocket 通信。发现 WebSocket 握手请求中携带了会话 cookie，但服务端没有校验 Origin 头。这意味着任何网站都可以向这个 WebSocket 服务发起连接，只要用户浏览器中存有目标站点的 cookie。这是跨站 WebSocket 劫持的典型条件。

三、漏洞发现

我进一步分析了 WebSocket 通信的协议。游戏中的下注、转账、聊天等操作都通过 WebSocket 消息实现。消息格式是 JSON，包含操作类型和参数。我确认了如果能够劫持 WebSocket 连接，就能以受害者的身份发送任意操作指令。

四、漏洞利用

我构造了一个跨站 WebSocket 劫持的页面。页面代码通过 new WebSocket("wss://目标") 向目标发起连接，由于浏览器会自动携带目标站点的 cookie，连接会以已登录用户的身份建立。页面中还包含了发送恶意指令的脚本，如发起转账、修改账户信息等。

五、权限获取

我诱导一个已登录的测试账户访问了这个恶意页面。页面成功建立了 WebSocket 连接，并以该账户身份发送了操作指令。我验证了可以通过劫持实现账户接管，包括查看账户余额、发起下注操作等。至此，WebSocket 劫持漏洞被完整验证。

六、复盘总结

这次测试的核心教训是：WebSocket 的鉴权不能只依赖 cookie。修复建议：第一，WebSocket 握手时校验 Origin 头，只允许白名单域名；第二，在 WebSocket 连接建立后进行二次鉴权，如校验一个短期有效的 token；第三，对 WebSocket 消息中的敏感操作做权限校验；第四，考虑使用 WSS 加密传输，并对敏感操作增加二次确认。

本文为授权安全评估实录，目标均已脱敏（IP 为文档保留段），仅用于安全研究与学习交流。