28WebSocket

## 概述

WebSocket 是一种基于 TCP 协议的全双工（Full-Duplex）通信协议，旨在解决传统 HTTP 协议 “请求 - 响应” 模式下实时通信效率低的问题。

它允许客户端（如浏览器）与服务器建立持久连接，双方可在连接保持期间随时向对方发送数据，无需反复建立新连接，广泛应用于实时聊天、在线游戏、金融行情推送、物联网监控等场景。

## 特性

相比 HTTP，WebSocket 具备以下关键优势，使其成为实时通信的首选方案：

全双工通信：客户端和服务器可同时双向发送数据，打破 HTTP“客户端请求→服务器响应” 的单向限制（例如：聊天时双方可同时发消息，无需等待对方回复）。

持久连接：连接建立后长期保持，避免 HTTP 每次通信都需重新握手（TCP 三次握手、TLS 协商等），大幅减少网络开销。

低传输开销：HTTP 每次请求需携带完整头部（如 Cookie、User-Agent 等），而 WebSocket 仅在握手阶段使用 HTTP 协议，后续数据传输采用轻量级 “帧（Frame）” 结构，头部仅 2-14 字节，带宽利用率极高。

原生跨域支持：通过 Origin 头校验实现跨域控制，无需依赖 JSONP、CORS 等 HTTP 跨域方案，且支持更灵活的权限配置。

二进制与文本兼容：可直接传输文本数据（如 JSON、UTF-8 字符串）或二进制数据（如图片、音频、Protobuf 序列化数据），无需额外编码转换。

## 工作原理

WebSocket 通信分为 “握手建立连接” 和 “双向数据传输” 两个阶段，本质是 “基于 HTTP 升级的 TCP 持久连接”。

> 阶段 1：握手（Handshake）—— 从 HTTP 升级到 WebSocket

客户端与服务器通过一次特殊的 HTTP 请求完成 “协议升级”，建立 WebSocket 连接，核心步骤如下：

客户端发送 “升级请求”：

客户端（如浏览器）发起 GET 请求，通过 HTTP 头部明确告知服务器 “希望升级为 WebSocket 协议”，关键头部字段如下：

```http
GET /ws/chat HTTP/1.1
Host: example.com
Upgrade: websocket  # 核心：声明要升级的协议为 WebSocket
Connection: Upgrade  # 核心：声明“连接需要升级”
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==  # 随机生成的Base64字符串，用于服务器验证
Sec-WebSocket-Version: 13  # 必须为13（当前标准版本，RFC 6455）
Origin: https://example.com  # 客户端来源，用于跨域校验
```

Sec-WebSocket-Key：客户端随机生成的 16 字节数据（Base64 编码），并非用于加密，而是防止 “误触发升级”（服务器需通过特定算法验证该值）。

服务器响应 “升级成功”：

服务器验证请求合法性（如 Sec-WebSocket-Version 是否为 13、Origin 是否允许跨域、Sec-WebSocket-Key 是否有效）后，返回 HTTP 101 状态码（Switching Protocols），并携带确认信息：

```http
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=  # 服务器对Sec-WebSocket-Key的校验结果
```

Sec-WebSocket-Accept 生成规则：将 Sec-WebSocket-Key 与固定字符串 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 拼接，再进行 SHA-1 哈希计算，最后将结果 Base64 编码。
客户端会验证该值，确认服务器确实支持 WebSocket 协议，避免连接被伪造。

连接建立：客户端验证 Sec-WebSocket-Accept 成功后，HTTP 连接正式升级为 WebSocket 连接，后续通信完全基于 TCP 协议，与 HTTP 无关。

> 阶段 2：双向数据传输（基于 “帧” 结构）

连接建立后，客户端和服务器通过 “帧（Frame）” 格式传输数据，每个帧包含 “头部” 和 “ payload（数据载荷）” 两部分：

帧头部（2-14 字节）：包含帧类型、数据长度、掩码标识等控制信息，核心字段如下：

| 字段           | 含义                                                         |
| -------------- | ------------------------------------------------------------ |
| FIN            | 1 表示当前帧是 “最后一帧”（防止数据分片），0 表示后续还有帧  |
| Opcode         | 帧类型（如 0x01 = 文本帧、0x02 = 二进制帧、0x08 = 关闭帧、0x09= ping 帧） |
| Mask           | 1 表示客户端发送的帧需 “掩码处理”（服务器发送的帧无需掩码，强制要求） |
| Payload Length | 数据载荷长度（12 位 / 16 位 / 64 位，支持最大 2^63-1 字节数据） |

掩码机制：客户端发送数据时，需用 4 字节随机 “掩码密钥” 对 payload 进行异或运算，服务器接收后用相同密钥解密。该机制用于防止 “恶意客户端伪造数据格式攻击服务器”，是协议强制要求（服务器若收到未掩码的客户端帧，必须关闭连接）。

数据分片：若传输大文件（如 100MB 视频），可将数据拆分为多个帧（FIN=0），最后一帧标记 FIN=1，避免单次传输占用过多带宽。

## 典型应用场景

WebSocket 因 “实时性、低开销” 的特性，适用于所有需要 “双向实时交互” 的场景：

实时聊天 / 社交：如微信网页版、Discord、在线客服系统，支持双方即时发送消息、表情、文件。

在线游戏：如多人实时对战游戏（如王者荣耀网页版），需实时同步玩家位置、操作指令（WebSocket 低延迟特性关键）。

金融行情推送：如股票、加密货币行情平台（如 Binance、同花顺），需每秒推送价格波动、成交数据（避免 HTTP 轮询的高频请求压力）。

协同办公工具：如腾讯文档、飞书在线表格，支持多用户实时编辑、光标位置同步（无需刷新页面即可看到他人修改）。

物联网（IoT）监控：如智能家居控制面板，实时接收设备状态（如空调温度、摄像头画面），并向设备发送控制指令（如 “关闭灯光”）。

实时日志 / 监控：如服务器运维平台（如 Grafana），实时推送 CPU 使用率、内存占用、错误日志，无需手动刷新页面。

## 与 HTTP 区别

很多人会混淆 WebSocket 和 HTTP，两者本质都是基于 TCP，但设计目标完全不同，核心区别如下：

| 对比维度   | HTTP（1.1/2/3）                                   | WebSocket（RFC 6455）                          |
| ---------- | ------------------------------------------------- | ---------------------------------------------- |
| 通信模式   | 单向（请求 - 响应），客户端主动发起请求           | 全双工，客户端 / 服务器可同时发送数据          |
| 连接持续性 | 短连接（默认无连接，HTTP/2 可复用连接但仍需请求） | 长连接，建立后持续保持，直到主动关闭           |
| 实时性     | 低（需通过 “轮询”“长轮询” 模拟实时，开销高）      | 高（连接持久，数据即时推送，无额外请求开销）   |
| 传输开销   | 每次请求需携带完整 HTTP 头部（通常数百字节）      | 仅握手阶段有 HTTP 头部，后续帧头部仅 2-14 字节 |
| 适用场景   | 静态资源加载（网页、图片）、API 接口调用          | 实时聊天、游戏、行情推送、IoT 监控             |

## WebSockets 安全漏洞

原则上，几乎任何网络安全漏洞都可能与 WebSockets 有关：

- 传输到服务器的用户提供的输入可能会以不安全的方式处理，从而导致 SQL 注入或 XML 外部实体注入等漏洞。
- 通过 WebSockets 发现的一些盲漏洞可能只能使用带外 (OAST) 技术检测到。
- 如果攻击者控制的数据通过 WebSockets 传输给其他应用程序用户，则可能会导致 XSS 或其他客户端漏洞。

## 靶机练习

### 操纵 WebSocket 消息来利用漏洞

影响 WebSocket 的大多数都是基于输入的漏洞，通过篡改 WebSocket 消息的内容来发现和利用。

例如，假设一个聊天应用程序使用 WebSocket 在浏览器和服务器之间发送聊天消息。当用户输入聊天消息时，类似如下的 WebSocket 消息会被发送到服务器：

```txt
{"message":"Hello Carlos"}
```

消息的内容被传输（再次通过 WebSockets）给另一个聊天用户，并在用户的浏览器中呈现如下：

```txt
<td>Hello Carlos</td>
```

在这种情况下，如果没有其他输入处理或防御措施，攻击者可以通过提交以下 WebSocket 消息执行概念验证 XSS 攻击：

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

靶机地址：https://portswigger.net/web-security/websockets/lab-manipulating-messages-to-exploit-vulnerabilities

已知：网上商店有一个使用 WebSockets 实现的实时聊天功能，并且提交的聊天消息将由支持代理实时查看。。

任务：使用 WebSocket 消息在支持代理的浏览器中 触发弹出窗口。

1、访问靶机地址，发现实时聊天工具。

![image-20250910135534650](https://oss.maolin101.com/image-20250910135534650.png-101.webp)

![image-20250910135542532](https://oss.maolin101.com/image-20250910135542532.png-101.webp)

![image-20250910135552776](https://oss.maolin101.com/image-20250910135552776.png-101.webp)

输入的内容直接显示在页面中。

2、注入特殊字符呢？

```javascript
<script>alert(2)</script>
```

![image-20250910135738304](https://oss.maolin101.com/image-20250910135738304.png-101.webp)

也进行了输出，但是并没有弹框。

3、通过burp，抓取数据包进行分析。

![image-20250910135947630](https://oss.maolin101.com/image-20250910135947630.png-101.webp)

输入的尖括号被HTML代码转义了。

4、构造payload，进行替换。

```javascript
<img src=0 onerror=\"alert('666')\" >
```

![image-20250910140554862](https://oss.maolin101.com/image-20250910140554862.png-101.webp)

5、过关。

![image-20250910140618620](https://oss.maolin101.com/image-20250910140618620.png-101.webp)

![image-20250910140516468](https://oss.maolin101.com/image-20250910140516468.png-101.webp)

### 操纵 WebSocket 握手来利用漏洞

某些 WebSocket 漏洞只能通过 操纵 WebSocket 握手来发现和利用，这些漏洞往往涉及设计缺陷，例如：

- 错误地信任 HTTP 标头来执行安全决策，例如X-Forwarded-For标头。
- 会话处理机制存在缺陷，因为处理 WebSocket 消息的会话上下文通常由握手消息的会话上下文决定。
- 应用程序使用的自定义 HTTP 标头引入的攻击面。

靶机地址：https://portswigger.net/web-security/websockets/lab-manipulating-handshake-to-exploit-vulnerabilities

已知：网上商店有一个使用 WebSockets 实现的实时聊天功能。

任务：使用 WebSocket 消息在支持代理的浏览器中 触发弹出窗口。

1、通过burp抓包，访问靶机中的实时聊天工具，并输入特殊字符。

```javascript
<script>alert('2')</script>
```

![image-20250910143434995](https://oss.maolin101.com/image-20250910143434995.png-101.webp)

同样被进行了编码，进行替换。

![image-20250910143451808](https://oss.maolin101.com/image-20250910143451808.png-101.webp)

2、显示已断开连接。

![image-20250910143550579](https://oss.maolin101.com/image-20250910143550579.png-101.webp)

再次刷新，发现IP地址被列出黑名单。

![image-20250910143704022](https://oss.maolin101.com/image-20250910143704022.png-101.webp)

3、抓包分析数据包。

![image-20250910143741315](https://oss.maolin101.com/image-20250910143741315.png-101.webp)

4、如果加一个请求来源呢？

```http
X-Forwarded-For: 2.2.2.2
```

![image-20250910143830333](https://oss.maolin101.com/image-20250910143830333.png-101.webp)

重新链接成功。

![image-20250910143847854](https://oss.maolin101.com/image-20250910143847854.png-101.webp)

5、再次构造payload进行发送。

```javascript
<img src=1 oNeRrOr=alert1>
```

![image-20250910144230586](https://oss.maolin101.com/image-20250910144230586.png-101.webp)

### 安全漏洞的核心根源

WebSocket 连接在建立后，会形成一个长期的、双向的通信通道。对于这个通道而言：

绕过了浏览器同源策略的部分限制：浏览器会允许任何页面与远程服务器建立 WebSocket 连接，但会通过 Origin 头告知服务器请求来源。是否验证这个来源，完全取决于服务器。

复用现有认证：浏览器会自动在握手请求中携带目标域下的 Cookie 等认证凭证。这使得攻击者可以更容易地发起跨站请求。

通信协议不同：握手后的通信不再遵循 HTTP，因此传统的 Web 应用防火墙（WAF）可能无法正确解析和检测其中的恶意载荷。

## 常见漏洞场景与防护措施

> 1跨站 WebSocket 劫持 (Cross-Site WebSocket Hijacking, CSWSH)

攻击原理：

1. 用户登录了正规网站 example.com，该站点使用 WebSocket。
2. 用户的浏览器中保存了 example.com 的会话 Cookie。
3. 用户访问了恶意网站 evil.com。
4. evil.com 的页面中包含一段脚本，直接与 wss://example.com/chat 建立 WebSocket 连接。
5. 浏览器会自动在握手请求中携带 example.com 的 Cookie，从而成功通过服务器认证。
6. 现在，恶意脚本可以通过这个被劫持的 WebSocket 连接，以该用户的身份向服务器发送任意指令（例如转账、修改资料、窃取隐私消息），并接收服务器的响应。

与 CSRF 的区别：CSRF 攻击通常是一次性的（如提交一个表单），而 CSWSH 会建立一个持久的双向通道，攻击者可以通过这个通道进行多次交互，危害极大。

防护措施：

- 验证 Origin 头：在服务器端，严格检查握手请求中的 Origin 或 Sec-WebSocket-Protocol 头，只允许来自受信任域的连接。这是最重要的防线。
- 使用令牌（Token）验证：在 WebSocket 握手请求的 URL 参数或头中加入一个随机的、与用户会话绑定的 CSRF Token，并在服务器端验证其有效性。恶意网站无法读取跨域页面的 Token，因此无法伪造正确的握手请求。

> 2. 敏感数据泄露

攻击原理：服务器没有对客户端请求进行严格的授权检查，导致用户可以通过 WebSocket 访问到本无权访问的数据。

- 垂直越权：普通用户请求了管理员才能访问的数据。
- 水平越权：用户A通过修改参数，请求了用户B的数据（如 {"userId": "B", "getMessages": true}）。

防护措施：

- 实施授权检查：对每一个通过 WebSocket 发起的数据请求，服务器都必须验证当前已认证的用户是否有权限执行该操作或访问所请求的数据。绝不能假设“连接已建立”就等于“拥有所有权限”。

> 3. 输入验证与注入攻击

攻击原理：服务器接收客户端通过 WebSocket 发送的数据，如果未经验证、清理或转义，就直接处理（如存入数据库、输出到其他用户的页面、执行系统命令），就会导致传统漏洞。

- SQL 注入：消息内容被拼接到数据库查询中。
- 跨站脚本（XSS）：服务器将收到的恶意脚本消息广播给其他用户，导致在其他用户的浏览器中执行。
- 命令注入：服务器将消息内容作为系统命令执行。

防护措施：

- 严格输入验证：采用“白名单”原则，对客户端发送的所有数据进行严格的类型、长度、格式和范围的检查。
- 上下文相关的输出编码：在将数据发送给其他客户端或插入数据库前，必须进行正确的转义和编码。
- 使用参数化查询：防止数据库注入。

> 4. 拒绝服务 (Denial of Service - DoS)

攻击原理：WebSocket 连接是长期的，会占用服务器内存、CPU 和套接字句柄等资源。攻击者可以：

1. 建立大量 WebSocket 连接并保持，耗尽服务器的可用连接数。
2. 发送非常巨大的消息（如 1GB 的二进制数据），耗尽服务器内存。
3. 快速发送大量消息，耗尽服务器 CPU 资源。

防护措施：

- 资源限制：对单个 IP 的连接数、消息发送速率、单个消息的大小进行限制。
- 设置超时：自动关闭不活跃的空闲连接。
- 使用负载均衡和反向代理：使用 Nginx 等工具，可以在反向代理层实施连接限制和保护，避免后端服务器被直接打垮。

> 5. 中间人攻击与窃听

攻击原理：使用未加密的 ws:// 协议时，所有通信内容以明文传输。攻击者可以在网络链路上的任何节点（如公共 WiFi）窃听数据，甚至篡改通信内容。

防护措施：

- 强制使用 wss://：wss:// 是基于 TLS/SSL 加密的 WebSocket，等同于 HTTPS。它能有效防止数据窃听和篡改。生产环境必须使用 wss://。

> 6. 协议实现漏洞

攻击原理：WebSocket 协议实现本身（客户端或服务器端库）可能存在漏洞，例如：

- 处理异常格式的帧（畸形帧攻击）可能导致缓冲区溢出。
- 对 Sec-WebSocket-Key 验证不正确。
- 内存泄漏。

防护措施：

- 使用成熟、活跃维护的库：选择广泛使用、社区活跃、定期发布安全更新的库（如 ws for Node.js）。
- 保持依赖更新：定期更新库到最新版本，以修复已知的安全漏洞。