WebSocket劫持漏洞本质是服务端未校验Origin头导致CSWSH，攻击者可诱导用户访问恶意页面并复用其Cookie建立合法连接；手动检测需篡改Origin后观察是否仍返回101状态码，自动化验证需用websocket-client库显式传入恶意Origin头。
WebSocket劫持漏洞的本质是Origin校验缺失
CSWSH（Cross-Site WebSocket Hijacking）不是“连接被黑”，而是服务端没验证 Origin 头就接受了 WebSocket 升级请求。攻击者只要诱导用户访问恶意页面，就能用其身份建立合法 WebSocket 连接——因为浏览器会自动带上用户 Cookie 和 Origin，而服务端若只校验 Cookie、忽略 Origin，就等于放行。
手动检测：用浏览器开发者工具抓握手请求
打开目标网页，切换到「Network」标签页，筛选 ws 或 wss，找到 WebSocket 连接的初始 HTTP 请求（通常是 GET /xxx）。点开它，检查请求头：
-
Origin值是否为当前域名（如https://target.com） - 是否存在
Sec-WebSocket-Key和Upgrade: websocket - 响应状态码是否为
101 Switching Protocols
关键动作：右键该请求 → 「Copy」→ 「Copy as cURL (bash)」，粘贴到终端，把 -H 'Origin: https://evil.com' 替换掉原始 Origin，再执行。如果仍返回 101，说明存在劫持风险。
自动化验证：用 Python 脚本伪造 Origin 发起连接
依赖 websocket-client 库，重点在于绕过浏览器自动设置的 Origin，手动控制请求头：
立即学习“前端免费学习笔记（深入）”；
import websocket
ws = websocket.WebSocket()
# 手动构造 Upgrade 请求，注入恶意 Origin
headers = {
"Origin": "https://attacker.com",
"Cookie": "session=abc123; path=/"
}
ws.connect("wss://target.com/chat", header=headers)
print(ws.recv()) # 若能收到服务端消息，即确认可劫持注意：websocket-client 默认不发 Origin，必须显式传入 header 参数；若服务端还校验 Referer 或 Token，需一并伪造。
容易被忽略的两个细节
一是很多接口在 WebSocket 握手后才做权限校验（比如收第一条业务消息时），所以即使握手成功，后续发 {"type":"get_profile"} 被拒绝，也不能排除劫持可能——得看拒绝时机；二是部分服务端用 Host 头替代 Origin 校验，此时要同步篡改 Host 并观察响应变化。
