WebSocket API安全风险解读

WebSocket协议是基于TCP的一种新的网络协议。它实现了客户端与服务器全双工（full-duplex）通信，即允许服务器主动发送信息给客户端。因此，在WebSocket中，客户端和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输，这样也使得客户端和服务器之间的数据交换变得更加简单。

• 较少的控制开销。在连接建立后，服务器和客户端之间交换数据时，用于协议控制的数据包头部相对较小。在不包含扩展的情况下，对于服务器到客户端的内容，此头部大小只有2至10字节（和数据包长度有关）；对于客户端到服务器的内容，此头部还需要加上额外的4字节的掩码。

• 更强的实时性。由于协议是全双工的，所以服务器可以随时主动给客户端下发数据。

• 保持连接状态。与HTTP不同的是，Websocket需要先建立连接，这就使得其成为一种有状态的协议，之后通信时可以省略部分状态信息。而HTTP请求可能需要在每个请求都携带状态信息（如身份认证等）。

• 更好的二进制支持。Websocket定义了二进制帧，相对HTTP，可以更轻松地处理二进制内容。

• 可以支持扩展。Websocket定义了扩展，用户可以扩展协议、实现部分自定义的子协议。

• 更好的压缩效果。相对于HTTP压缩，Websocket在适当的扩展支持下，可以沿用之前内容的上下文，在传递类似的数据时，可以显著地提高压缩率。

• HTTP 是一个无状态的协议，使客户端向服务器请求资源，并从服务器接收响应。客户端使用 HTTP 请求/响应语法，即请求发送到服务器之后，服务器向客户端返回 HTML 文件、图像和其他媒体内容。

• WebSocket 通信协议尝试在较大范围内改进 Web 实时通信和插件技术，并提供全双工、基于事件的通信而无需采用低效的轮询方式。开发人员可以从 Web 浏览器的 JS 端轻松地创建 WebSocket 连接并发送数据，进而实现应用程序的实时数据传输的实现。

• 由于 WebSocket 是面向消息的，因此它更加适用于实时通信，而 HTTP 更适用于请求和服务器-客户端通信的响应。

Websocket 使用 ws 或 wss 的统一资源标志符（URI），其中 wss 表示使用了 TLS 的 Websocket，类似于HTTP协议的http和https。wss协议通过TLS连接建立一个WebSocket，即加密传输；ws协议即明文传输。

ws://echo.websocket.orgwss://echo.websocket.org

WebSocket API与传统API一样都是由通信协议、域名、版本号、路径、请求参数等要素组成，只是由于WebSocket API在完成握手流程之后，客户端和服务端之间就创建了持久性的连接，并且可以直接用文本消息或者二进制消息进行通信的数据交互，这样我们在WebSocket API流量报文中看到的一般都是JSON格式文本消息。

从开发的角度，WebSocket API还包括了：

• 构造函数，构造函数的语法示例为：const myWebSocket = new WebSocket(url [, protocols])，其中url表示连接的 URL；protocols表示为一个协议字符串或者一个包含协议字符串的数组，为可选。

• 属性：属性分为很多主要有bufferedAmount，表示未发送至服务器的字节数；onopen，表示用于指定连接成功后的回调函数，等等。

• 方法：方法主要分为close和send，分别表示WebSocket关闭连接和数据传入服务器。

• 事件：事件主要有close、error、message、open。

WebSocket API作为一种重要客户端-服务器通信接口，究竟在哪些业务场景下能够用到WebSocket API呢？主要分为三大类：

• 实时数据更新的应用程序：对于一些需要服务端不断发送数据在客户端实时显示的应用，使用WebSocket API作为数据传输接口无疑是最好的选择。
• 游戏应用程序：在游戏应用中，一般的场景是服务器需要不断接收数据，无需刷新UI，传输的数据就会在屏幕上生效，UI也会自动刷新，不需要建立新的连接。
• 聊天应用程序：聊天应用程序一般会有较长的连接状态，以方便用户与用户之间的实时交流，采用WebSocket API只需建立一次连接便可以实现一对一的消息传输，并且保持长时间的通讯连接。

具体业务场景列举：

WebSocket API的安全风险主要分为两大类：常规攻击风险和特有攻击风险。以下是这两大类风险的详细解读。

（1）消息体输入漏洞

和HTTP协议一样，WebSocket API在传输消息的时候一般采用json格式传输文本，所以对于消息体中参数依然可以可以进行SQL注入、XSS、命令执行、文件读取、SSFR、任意文件上传......等常规输入性漏洞攻击。

漏洞案例：

在线聊天应用中使用WebSocket API在客户端和服务端之间传输消息。当一个用户输入聊天消息时，如下的一个WebSocket消息被发送到服务端：

服务端会将这个消息内容通过WebSocket API转发给另外一个用户，然后在另一个用户的浏览器中被JS渲染为一段HTML代码。

当服务器没有对转发的内容做安全防御或过滤时，通过修改WebSocket API消息体实施xss攻击。

（2）身份认证绕过

WebSocket API没有规定服务器在握手阶段应该如何认证客户端身份。服务器可以采用任何 HTTP 服务器的客户端身份认证机制，如 cookie认证，HTTP 基础认证，TLS 身份认证等，在WebSocket API在身份认证面临的攻击风险和传统的API面临的风险是一样的，因此WebSocket API同样面临着OWASP API 2023十大安全风险中的API2：身份认证失效风险。

（3）授权失效

同身份认证一样，WebSocket API没有明确指定任何授权方式，API中用户资源访问等的授权策略由服务端或开发者实现。WebSocket API也会存在和传统Web应用相同的安全风险，如：垂直越权、水平越权、未授权访问等等安全风险。所以WebSocket API同样面临OWASP API 2023十大安全风险中API1:对象级别授权失效、API3:对象属性级别授权失效、API5:功能级别授权失效的安全风险。

（4）拒绝服务

WebSocket API同样易遭受拒绝服务攻击，其面临风险分为客户端拒绝服务风险和服务端拒绝服务风险。

• 客户端拒绝服务：WebSocket 连接限制不同于HTTP连接限制，WebSocket有一个更高的连接限制，不同的浏览器的最大连接数也存在差异，通过发送恶意内容，占用所有Websocket，导致浏览器资源耗尽，引起拒绝服务。

• 服务端拒绝服务：WebSocket建立的是持久连接，只有客户端或服务端其中一方发起关闭连接的请求，连接才会关闭。攻击者可以通过发起请求并建立大量的连接，导致服务器资源耗尽，引发拒绝服务攻击。

4.2 WebSocket API 特有攻击面

（1）跨站WebSockets劫持

在WebSocket API发起WebSocket握手请求时，浏览器会在请求中添加一个名为Origin的HTTP头，Oringin字段表示发起请求的源，以此来防止未经授权的跨站点访问请求。WebSocket 规范中没有强制规定握手阶段的 Origin 头是必需的，且WebSocket不受浏览器同源策略的限制。如果服务端没有针对Origin头部进行验证可能会导致跨站点WebSocket劫持攻击，当WebSocket握手请求仅依靠HTTP cookie进行会话处理并且不包含任何CSRF token或其他不可预测的值时，也有可能会造成这种漏洞。这攻击风险类似于JSONP劫持，是属于CSRF攻击的一种。

漏洞示例：

通过实时聊天发送聊天消息：

在WebSocket握手请求中发现仅仅是靠cookie进行会话处理，并没有CSRF的防护手段。

查看WebSocket历史消息记录。

在浏览器中找到漏洞利用服务器。

同时我们在burp设置一个burp client，这里模拟的是攻击者。

在漏洞利用服务器中贴入利用JS代码。

漏洞利用服务器并将漏洞利用程序传递给受害者，然后在攻击者也就是我们创建的burp client中返回了受害者相关敏感信息。

解码发现用户登陆凭证。

（2）中间人攻击

同样是出现在操控WebSocket握手流程时的攻击风险，可以通过获取并篡改WebSocket握手请求，实施以下攻击：

通过伪造客户端信息与服务器建立WebSocket连接；无条件信任HTTP头，导致某些安全策略可以被绕过。例如：X-Forwarded-For头，XSS绕过WAF；应用程序自定义的HTTP标头引入的攻击面。

漏洞案例：

在线聊天中使用了XSS攻击之后，攻击已被阻止，并且WebSocket 连接已终止。

拦截WebSocket 握手请求并使用X-Forwarded-For头来绕过黑名单。

一直采用这种方式进行绕过后，等到聊天框重新出现就说明绕过了黑名单的检测，并且可以实施xss攻击，后续步骤可以参考上述消息体输入漏洞攻击中的案例。