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. 阶段 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. 阶段 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=alert`1`>
```

![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）。
- **保持依赖更新**：定期更新库到最新版本，以修复已知的安全漏洞。