WebSocket作为一种全双工通信协议，已经被大量应用在实时聊天、在线游戏、金融数据推送等场景中。但很多开发者在部署时忽略了一个核心问题：WebSocket连接本身并不像HTTP那样有成熟的同源策略保护机制，这导致跨域资源共享（CORS）绕过和注入攻击成为两大高危漏洞。简单来说，攻击者可以通过构造恶意的WebSocket握手请求，绕过服务器的来源验证，直接建立连接并注入恶意数据，进而窃取用户会话、篡改实时通信内容甚至接管整个服务端逻辑。解决这个问题不是靠单一手段，而是需要从握手验证、来源白名单、消息过滤、速率限制等多个层面构建防御体系。
WebSocket跨域风险的本质是什么
传统HTTP请求有浏览器强制执行的同源策略，但WebSocket的握手阶段本质上是一个HTTP Upgrade请求。这个升级请求虽然也受同源策略约束，但很多服务器端实现为了方便，直接允许任意Origin头通过验证。攻击者只需要在自己的恶意页面中用JavaScript发起一个WebSocket连接，把Origin头改成目标网站的域名，如果服务端没有严格校验，连接就能建立成功。一旦连接建立，攻击者就可以像合法用户一样收发消息，这就是跨域风险的核心。
更危险的是，有些开发者为了调试方便，直接把WebSocket服务暴露在公网上，不做任何来源限制。这种情况下，任何人都可以连接，不需要经过任何认证页面，直接通过脚本就能接入。尤其是在微服务架构中，WebSocket网关如果没有独立的鉴权模块，整个内部通信链路都可能被外部渗透。
跨域防护的具体实现方案
第一步，在WebSocket握手阶段严格校验Origin头。服务端必须维护一个允许连接的来源白名单，只有白名单内的域名才允许建立连接。以下是一个Node.js环境下使用ws库的示例：
const WebSocket = require('ws');
const allowedOrigins = ['https://www.example.com', 'https://app.example.com'];
const wss = new WebSocket.Server({ port: 8080 });
wss.on('headers', (headers, req) => {
const origin = headers.origin;
if (!allowedOrigins.includes(origin)) {
// 返回403禁止连接
return { statusCode: 403, headers: { 'Content-Type': 'text/plain' } };
}
});
wss.on('connection', (ws, req) => {
// 合法连接后的业务逻辑
ws.on('message', (message) => {
console.log('收到消息:', message);
});
});
第二步，不要仅依赖Origin头。因为Origin头是客户端发送的，可以被伪造。更可靠的方式是在握手阶段引入Token机制。客户端在发起WebSocket连接前，先通过HTTPS获取一个有时效性的连接Token，然后在WebSocket的URL参数或第一个消息中携带这个Token，服务端验证通过后才允许通信。这种方式把WebSocket的鉴权和HTTP的Session体系打通，安全性大幅提升。
第三步，配置WebSocket服务的网络层面访问控制。不要把WebSocket端口直接暴露在公网，应该通过反向代理（如Nginx）来中转，并在代理层做IP白名单和频率限制。Nginx配置示例如下：
location /ws {
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header Origin $http_origin;
# 限制每秒连接数
limit_req zone=ws_limit burst=5 nodelay;
# 只允许特定IP段访问
allow 192.168.1.0/24;
deny all;
}
WebSocket注入攻击的类型和原理
跨域只是入口问题，真正造成数据危害的是注入攻击。WebSocket注入主要有三种形式：消息内容注入、协议层注入和后端存储注入。
消息内容注入是最常见的。攻击者通过已建立的WebSocket连接发送精心构造的消息，这些消息可能包含SQL语句、XSS脚本片段或者命令执行代码。如果服务端直接把收到的消息拼接到数据库查询、日志记录或者返回给其他客户端，就会触发注入。比如一个聊天室场景，攻击者发送一条包含JavaScript代码的消息，如果其他用户的客户端直接渲染这条消息，就会执行恶意脚本。
协议层注入更隐蔽。WebSocket协议本身有帧结构，包括操作码、掩码位、payload长度等字段。如果服务端的WebSocket解析库存在漏洞，攻击者可以发送畸形帧导致缓冲区溢出或者服务崩溃。虽然现代库已经修复了大部分此类问题，但自研的解析器或者老旧版本的库仍然存在风险。
后端存储注入则是指WebSocket收到的数据被持久化到数据库或文件系统时，没有经过充分的转义和验证。这种攻击的危害是长期的，恶意数据会污染整个数据层，影响所有后续的查询和展示。
注入防护的核心策略
首先，对所有通过WebSocket接收的消息执行严格的输入验证。不要信任任何来自客户端的数据，哪怕是已经通过鉴权的连接。验证规则应该包括：消息长度限制、字符白名单、格式校验（如JSON Schema验证）。以下是一个消息验证的示例：
const Joi = require('joi');
const messageSchema = Joi.object({
type: Joi.string().valid('text', 'image', 'system').required(),
content: Joi.string().max(2000).required(),
userId: Joi.string().uuid().required()
});
wss.on('connection', (ws) => {
ws.on('message', (rawMessage) => {
try {
const message = JSON.parse(rawMessage);
const { error, value } = messageSchema.validate(message);
if (error) {
ws.send(JSON.stringify({ status: 'error', msg: '消息格式非法' }));
return;
}
// 通过验证后处理业务逻辑
handleValidMessage(value);
} catch (e) {
ws.close(1008, '非法消息格式');
}
});
});
其次，对输出到其他客户端的消息进行编码转义。如果消息内容会被渲染为HTML，必须进行HTML实体编码；如果会被用于SQL查询，必须使用参数化查询而不是字符串拼接。永远不要把WebSocket消息直接拼接到SQL语句或者Shell命令中。
第三，实施消息频率限制和异常行为检测。单个WebSocket连接在短时间内发送大量消息，或者发送的消息模式异常（如包含大量特殊字符、超长字符串），都应该被标记并限制。可以使用滑动窗口算法来统计每个连接的消息频率，超过阈值就暂时断开连接并记录日志。
架构层面的深度防御建议
从架构角度来看，WebSocket服务不应该直接暴露业务逻辑，而应该作为一个独立的通信层存在。具体来说，建议采用网关加微服务的架构：WebSocket网关只负责连接管理、鉴权和消息路由，具体的业务处理交给后端的微服务通过内部消息队列（如Redis Pub/Sub、RabbitMQ）来完成。这样即使WebSocket层被攻破，攻击者也无法直接触及核心业务数据。
另外，务必启用WSS（WebSocket Secure）而不是WS。WSS通过TLS加密传输，可以防止中间人攻击和数据窃听。证书配置要规范，不要使用自签名证书在生产环境中运行。同时，TLS握手阶段本身也提供了一层来源验证，因为证书绑定了域名。
日志和监控也是不可忽视的环节。所有WebSocket连接的建立、断开、消息收发都应该记录详细日志，包括来源IP、User-Agent、连接时长、消息大小等。配合实时监控告警，当出现异常连接模式时能够第一时间响应。建议使用ELK或者类似的日志分析平台来做长期的行为分析。
容易被忽视的细节问题
很多团队在做WebSocket安全防护时，会忽略几个细节。第一是连接超时处理。如果一个WebSocket连接长时间没有活动，应该主动关闭并清理资源，防止被利用作为持久化的攻击通道。第二是重连机制的安全设计。客户端断线重连时，不能无条件自动重连，应该有指数退避策略，并且每次重连都要重新验证Token。第三是跨子域名的处理。如果你的服务分布在多个子域名下，每个子域名的WebSocket服务都需要独立配置Origin白名单，不能假设主域名的验证能覆盖子域名。
还有一个常见误区是认为WebSocket因为是长连接所以比HTTP更安全。实际上恰恰相反，长连接意味着攻击窗口更大，一旦建立连接，攻击者有更多时间和机会发送恶意数据。而且WebSocket连接不像HTTP请求那样有天然的请求-响应对应关系，消息的来源追踪更困难，这对安全审计提出了更高要求。
总结与行动建议
WebSocket的跨域和注入风险不是理论问题，而是每天都在发生的真实威胁。防护的核心思路是：握手阶段严控来源，通信阶段严验内容，架构层面隔离风险，运维层面持续监控。不要依赖单一的防护手段，要建立纵深防御体系。对于已经上线的WebSocket服务，建议立即做一次安全审计，重点检查Origin验证逻辑、消息过滤规则和网络暴露面。对于正在开发的新项目，从设计阶段就把WebSocket安全纳入整体安全架构中，而不是事后补救。安全不是功能的对立面，而是功能能够持续稳定运行的基础保障。
