浅谈WebSocket安全风险

前言

在现代Web开发中，WebSocket协议因其高效的实时双向通信能力而被广泛应用于聊天、在线游戏、实时数据推送等场景。然而，随着WebSocket的普及，其相关的安全漏洞也逐渐浮出水面。

websocket是什么？

WebSocket 是一种基于 TCP 的网络通信协议，旨在为 Web 应用提供一种 全双工、持久化、双向通信 的机制。它允许客户端（如浏览器）与服务器之间建立一个 长期保持的连接，从而实现 实时、低延迟的数据交换，无需频繁地打开和关闭连接。WebSocket支持全双工通信，能够建立持久连接，延迟低，主要应用于实时聊天、在线游戏和实时数据推送等场景。

常见websocket安全漏洞   

篡改 WebSocket 消息体，测试服务端是否存在基于输入的漏洞，例如 XSS、SQL 注入、路径遍历等。

例如，一个具有聊天功能的Web程序使用WebSocket在客户端和服务端之间传输消息。当一个用户输入聊天消息时，如下的一个WebSocket消息被发送到服务端：

{"message":"Hello"}

当服务器没有对转发的内容做安全防御或过滤时，可能就会引发XSS攻击。

{"message":"<img src=1 onerror='alert(1)'>"}

某些有认证需求的API，WebSocket 服务端未对连接来源、身份进行认证，导致任意客户端可伪造连接与服务器通信，泄露敏感信息或操控操作。

使用websocat进行连接，发送消息测试，若返回用户数据，说明存在未授权访问。

连接：websocat.exe -v wss://0ae30012044ba3ba8097305600800035.web-security-academy.net/chat

发送消息：{"message":"body"}

WebSocket 长连接通信中，若存在返回多余调试信息、系统路径、异常堆栈等，可能泄露敏感信息，便于攻击者分析系统结构。

发送：

{"message":"getConfig"}

返回：

{"error":"File not found at /var/www/config/setting.json"}

如果 WebSocket 消息采用 JSON 传输，服务端 JSON 解析器存在缺陷，攻击者可尝试利用特殊符号"}]脱出 JSON 格式，影响后续解析或执行逻辑，导致报错或其他漏洞。

{"username":"admin"}"}

攻击者伪造握手请求：

GET /ws HTTP/1.1 

Host: target.com 

X-Forwarded-For: 127.0.0.1

若后台将X-Forwarded-For当作客户端真实 IP，可能导致管理端口开放或安全规则失效。

攻击者绕过验证：

GET /ws?uid=1 HTTP/1.1 

Cookie: session=xxxx

若服务端只基于 URIuid参数判断身份，存在权限绕过风险。

攻击者大量建立 WebSocket 长连接占用资源，或者在长连接内不断发送大体积消息，可能导致服务器资源耗尽，造成DoS（拒绝服务）效果。

部分盲漏洞（如 SSRF、命令注入、XXE）在 WebSocket 场景下无法直接在响应内查看回显，需借助带外探测平台如Burp Collaborator、ceye.io，检测服务端是否存在非法对外请求。

{"url":"http://attacker.ceye.io/test"}

观察带外服务平台是否接收到请求。

部分前端 WebSocket 实现存在逻辑缺陷，前端 JS 泄露Token、认证参数等信息。

WebSocket 是无状态的，但业务逻辑可能依赖消息顺序。

• 重放旧消息（如重复发送交易请求）。

• 乱序发送消息（如先发“确认”再发“请求”）。

跨站 WebSocket 劫持（也称为跨源 WebSocket 劫持）涉及 WebSocket 握手过程中的跨站请求伪造 (CSRF) 漏洞。当 WebSocket 握手请求仅依赖 HTTP Cookie 进行会话处理，且不包含任何 CSRF 令牌或其他不可预测的值时，就会出现这种情况。

攻击者可以在自己的域名上创建一个恶意网页，与存在漏洞的应用程序建立跨站 WebSocket 连接。该应用程序将在受害者用户与其会话的上下文中处理该连接。

攻击者的页面随后可以通过该连接向服务器发送任意消息，并读取从服务器返回的消息内容。这意味着，与常规的CSRF不同，攻击者可以与受感染的应用程序进行双向交互。

websocket安全漏洞案例

例如，在这种情况下，如果没有其他输入处理或防御措施，攻击者可以通过提交以下 WebSocket 消息，执行 XSS 攻击payload就可以造成前端代码注入，看到这段消息的用户就会成为受害者：

WebSocket 握手是客户端与服务器之间建立连接的第一步，其本质是通过 HTTP 协议进行一次协议升级，将通信从 HTTP 升级为 WebSocket，从而实现全双工、低延迟的双向通信。某些 WebSocket 漏洞只能通过操纵 WebSocket 握手来发现和利用。这些漏洞往往涉及设计缺陷，例如：

• 错误地信任 HTTP 标头来执行安全决策，例如 X-Forwarded-For 标头

• 会话处理机制的缺陷，因为 WebSocket 消息处理中的会话上下文通常由握手消息的会话上下文决定

• 应用程序使用的自定义 HTTP 头引入的攻击面

例如下面这种情况下，服务端通过客户端IP来执行安全策略，攻击者就可以在重新建立连接的时候通过 X-Forwarded-For 标头来伪造IP，从而绕过安全机制：

重新注入恶意代码即可绕过防护：

跨站 WebSocket 劫持（也称为跨域 WebSocket 劫持）涉及 WebSocket 握手中的跨站请求伪造（CSRF）漏洞。当 WebSocket 握手请求完全依赖 HTTP Cookie 进行会话处理，且不包含任何 CSRF 令牌或其他不可预测值时，就会发生这种情况。

成功的跨站 WebSocket 劫持攻击通常会使攻击者能够：

• 冒充受害者用户执行未经授权的操作。

• 获取用户可以访问的敏感数据。

就 CSRF 攻击的常规条件而言，通常需要找到一个仅依赖 HTTP cookie 进行会话处理的握手消息，并且请求参数中不使用任何令牌或其他不可预测的值。例如，以下 WebSocket 握手请求可能容易受到 CSRF 攻击，因为唯一的会话令牌是通过 cookie 传输的：

GET /chat HTTP/1.1

Host: normal-website.com

Sec-WebSocket-Version: 13

Connection: keep-alive, Upgrade

Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2

Upgrade: websocket

例如，在下面这个场景中，攻击者利用跨站 WebSocket 劫持攻击来窃取受害者的聊天记录，从而进一步访问他们的账户：

WebSocket协议为现代Web应用提供了高效的实时通信能力，但其安全漏洞不容忽视。通过采取适当的防护措施：

• 使用 wss:// 协议（通过TLS的WebSocket）。

• 将WebSocket端点的URL硬编码，并且绝对不要将用户可控数据包含在这个URL中。

• 保护WebSocket握手消息免受CSRF攻击，以避免跨站WebSocket劫持漏洞。

• 将通过WebSocket接收的数据视为双向不可信数据。在服务器和客户端两端安全地处理数据，以防止基于输入的漏洞。

可以有效降低安全风险。

    《Testing for WebSockets security vulnerabilities》    

    《WebSocket 安全测试入门实践》    

原文始发于微信公众号（搜狐安全）：浅谈WebSocket安全风险