摘要：WebSocket协议是HTML5标准规范的一部分。它是一种新的网络通信协议，提供了客户端与服务器之间的全双工通信机制。WebSocket的出现为实时网络通信带来了利好消息，但相应的WebSocket漏洞也逐渐暴露出来，其中跨站点WebSocket劫持的危害性比较大，容易被忽视。本文主要探讨了WebScoket跨站劫持漏洞的原理，并提出了一种基于混合加密的一次性随机令牌方案来解决WebSocket跨站劫持漏洞，最后对该方案进行了测试，验证其有效性。
第一节. 导言
HTML5中的WebSocket协议是基于TCP的应用层通信协议，它参考了套接字的思想，在Web客户端和服务器之间建立了一个全双工的通信通道。在WebSocket通道上，客户端和服务器可以相互通信。WebSocket协议最大的特点是服务器可以主动向客户端发送数据，这对于HTTP协议来说基本上是不可能的，而且它的小头信息非常适合实时通信方案[1]。目前，主流浏览器已经支持WebSocket通信。
随着Internet的快速发展，B/S(Browser/Server)模式已经成为现代应用的主流，Web通信的安全性近年来逐渐受到开发者的重视[2]。WebSocket的诞生主要是为了解决传统B/S模式的实时性问题，因此通信的安全性对于WebSocket应用尤为重要[3]。
在Web即时通信中，WebSocket可以提高网络吞吐量，减少延迟，减轻服务器负担，但也带来了相应的安全隐患。例如，攻击者试图删除和修改用户数据，恶意拦截和窃取数据等。参考文献[4]指出，WebSocket的安全特性可以缓解一些特性的攻击，但近年来Websocket相关的安全漏洞频频曝光，其中最常见的漏洞是CSWSH(Cross-Site WebSocket Hijacking)。该漏洞由德国黑客Christian Schneider于2013年发现并披露，并命名为Cross-Site WebSocket Hijacking[5]。该漏洞容易被研究人员忽视，危害极大。
第二节 Websocket协议介绍
2011年，IEFI将WebSocket协议定义为国际标准RFC6455，并由RFC7936进行了补充。WebSocket 后来被纳入 HTML5 规范，其 API 也被 W3C 设定为标准。现在所有主流浏览器都支持它。WebSocket协议是一种基于TCP的应用层协议，它可以在客户端和服务器之间建立全双工通信通道，使双方能够更高效地相互发送和接收数据信息。WebSocket连接的建立需要经过连接请求、握手、连接建立三个步骤[6]，如图1所示。
图1.Websocket连接流程图 – Websocket连接流程图
WebSocket 连接握手是通过 HTTP 完成的。首先，浏览器客户端调用 WebSocket API 以启动连接请求。虽然请求地址以’ws’开头，但它本质上是一个HTTP请求，只是与普通的HTTP请求不同。图 2 是 WebSocket 连接请求消息的部分报头，其中 sec-websocket-key 字段是由客户端生成的 24 位基于 64 字符的随机序列，用于握手验证。
图2.Websocket请求消息的部分头颅
当服务器收到请求后，解析请求头并作出响应，如图3所示。响应状态码101表示连接成功，服务器被替换为WebSocket协议。其他状态码表示连接失败。响应报文中的Sec-Web Socket-Accept是由请求报文中的Sec-WebSocket-Key字段值按照相应算法生成的新字符序列。
图3.websocket握手响应消息的报头
浏览器客户端在收到响应后，确认服务器已经升级协议，然后按照同样的算法计算出之前的Sec-WebSocket-Key值，再与返回的Sec-Web Socket-Accept进行比较。如果两者一致，则握手成功，客户端升级到WebSocket协议，连接建立，双方可以互相发送数据。否则，连接失败。连接建立后，会一直保持到一方主动发送关闭请求或发生网络错误。浏览器客户端和服务器都可以主动关闭连接。
第三节.跨站点Websocket劫持
A. 脆弱性原则
图 4 跨网站网络插口劫持漏洞示意图。
WebSocket协议在握手阶段是基于HTTP的。它没有规定服务器在握手期间如何验证客户端的身份。因此，服务器一般采用HTTP客户端认证机制，如cookie、http基本认证等[5]、[7]。这就导致攻击者可以利用恶意网页伪装用户的身份，与服务器建立WebSocket连接。其攻击原理如图4所示。
首先，用户登录并浏览受信任的网站A，登录成功后，浏览器将用户认证信息保存在Cookie中。此后，用户的每次HTTP请求都会自动带上cookie来验证客户端用户的身份。如果恶意网站B在页面中植入与网站A建立WebSocket连接的握手请求，当用户在没有退出网站A的情况下访问恶意网站时，A网站的Cookie会自动添加到请求头中，而服务器并不知道。所以恶意网站可以冒充用户的身份，成功与服务器建立连接，然后窃取服务器消息或发送伪造的请求来篡改数据。
该漏洞的原理与跨站请求伪造(CSRF)[8]、[9]非常相似，但CSRF漏洞只能发送伪造请求，而跨站WebSocket劫持漏洞建立了完整的读/写双向通道，且不受同源策略的限制，所以跨站WebSocket劫持漏洞的危害更大。为此，Christian Schneider将该漏洞命名为 “劫持 “而非 “请求伪造”。
B. 漏洞防御
由于CSWSH和CSRF的原理相似，其解决的核心在于验证客户端的身份[8]，[9]。常见的解决方案有以下几种。
图形验证码。在每次连接请求前，向服务器请求一个图像验证码，然后手动输入，并附在请求中，以验证客户端的身份。这种方法安全性高，但每次都需要人工输入验证码，对用户的体检效果极差。
起源验证[5]，[7]。图2中的Origin字段表示请求的源地址。服务器可以检查请求头中的Origin字段，避免恶意连接请求。然而，Origin字段仅由浏览器提供。对于非浏览器客户端来说，这个字段是空的，攻击者可以伪造Origin头信息。
随机令牌。随机令牌是由服务器生成的随机序列，并在登录完成后发给客户端。客户端在每次请求时都会带上token。服务器设置一个拦截器来验证该值，以确定请求者的身份。这种方法效果很好，但是令牌的安全性难以保证，所以还存在令牌泄露[9]和重放攻击的问题。
参考文献[10]提出了一种随机参数名的CSRF防御方法。虽然可以防止攻击者伪造请求参数，但如果请求参数要由用户动态生成，这种方法就不适用了。特别是对于websocket，只有一次连接操作。所以随机化参数和随机令牌的区别不大，这种方法不适合防御CSWSH漏洞。
第四节.防御策略
本文提出了一种基于混合加密的一次性随机令牌方案。该方案可以使用协商加密的一次性令牌来验证客户端的身份，并能成功防止令牌泄露和重放攻击。
A. 混合加密
加密技术[11]、[12]一般分为对称加密和非对称加密两种。对称加密是用一个密钥将明文加密成密文，密文只有通过相同的密钥才能解密得到明文。非对称加密有一对用于加密和解密的密钥对：公钥和私钥。两者必须成对使用，一个用于加密，另一个用于解密。所谓公钥是公知的，私钥只有持有者才能知道。用公钥加密的密文，只能用相应的私钥来解密。或者用私钥加密的密文只能由相应的公钥解密。
对称加密和非对称加密，各有各的优缺点。将它们结合起来使用是一个不错的选择，可以弥补它们的不足。本文所采用的混合加密方法，就是利用非对称加密传输对称加密的密钥，再利用对称加密传输随机Token。这样可以保证客户端和服务器拥有相同的密钥，即使Token被泄露，攻击者也不知道加密密钥，因此无法伪造用户请求。
B. 设计方案
WebSocket连接是在HTTP握手的基础上完成的。本文设计的方案是在此基础上改为六次握手阶段。前四次握手用于登录和协商密钥，后两次握手用于建立WebSocket连接并返回新的令牌。
图5.防御方案流程图
如图5所示，步骤如下。
1.客户端向服务器请求公钥信息。
2.服务器将公钥信息返回给客户端。
3.客户端随机生成对称加密密钥，然后使用服务器的公钥对密钥和用户登录信息进行加密，最后发送给服务器。
4.服务器接收后，使用私钥对密文进行解密。获得客户端密钥和表单登录信息后，如果登录信息正确，则随机生成一串令牌，服务器将此令牌和客户端密钥保存起来。最后，将令牌和确认信息返回给客户端，协商完成。
5.当客户端建立连接时，用协商密钥对Token进行加密，并与WebSocket连接请求一起发送给服务器。
6.服务器使用协商密钥解密 Token 值，验证身份信息，并决定是否接受连接。如果确认身份信息，则同时销毁之前的Token，并生成新的Token，一起返回给客户端。
本方案首先采用公钥加密，保证登录信息和客户端密钥的安全。之后，利用协商好的密钥对Token Token进行加密，这样即使Token被泄露，如果没有密钥加密，服务器也无法验证Token信息，防止了Token泄露的风险。最后，在验证完成后，销毁之前的Token，发放新的Token，可以有效避免重放攻击。
第五节 实验结果与分析
本节主要检验所提出的设计方案的效果。
A. 实验平台和检测工具
测试实验以Ubuntu为服务器系统，node.js为Web容器，360安全浏览器为客户端。在防御方案的实现上，非对称加密采用RSA加密算法，对称加密采用AES加密算法。AES密钥长度和随机令牌长度统一规定为16位字符长度。
采用OW ASP ZAP软件作为实验检测工具。设置浏览器代理后，OW ASP ZAP可以抓取浏览器与服务器之间的数据包进行分析、渗透性检测等。实验主要利用ZAP抓取WebSocket请求连接数据包，修改参数后重新发送连接请求，看是否能成功连接到服务器。
B. 效果测试
图6显示了没有采取任何防御措施的实验结果。原点字段被修改，但连接仍然成功建立，说明存在跨站点WebSocket劫持漏洞。
图6.在没有任何防御措施的情况下成功建立劫持连接
图7.使用防御方案后，请求被重放，但连接失败。
图7是使用本文防御方案的实验结果。可以看出，WebSocket连接失败是因为服务器的Token值发生了变化。当重播请求时，服务器验证失败。
之后，取出捕获的响应数据包中的Token值，替换成请求数据包中的Token。而后再次发送请求，但连接再次失败，如图8所示。这是因为Token没有加密，服务器验证还是失败了。
图8.防御方案
使用防御方案后，Token被篡改，但连接失败。
从以上实验结果可以看出，本文提出的防御方案可以有效抵抗跨站WebSocket劫持漏洞。
引用
1.Jiahao Qin “Research and performance analysis of instant messaging based on WebSocket [J]” Mobile Communication vol. 41 no. 12 pp. 44-48 2017.
2.Xuejie Tong and Xufu Peng “Research on Security Algorithms of Web Communication [J]” Information Communication vol. 12 pp. 126-127 2018.
3.Chaoju Hu and Cong Gao “Research on New Features and Security of WebSocket [J]” Network Security Technology and Application vol. 11 pp. 55-56 2015.
4.Cong Gao Research on Application of Information Security Technology in WebSocket Real-Time Communication [D] North China Electric Power University 2016.
5.Jun Zhu Design and Implementation of WebSocket Security Subprotocol Based on Node Platform [D] Huazhong University of Science and Technology 2016.
6.Renwei Yi Research on Real-time Web Application Based on WebSocket [D] Wuhan University of Technology 2013.
7.Deyu Zeng “WebSocket Security Vulnerability and Its Repair [J]” Digital Technology and Application vol. 09 pp. 198 2016.
8.Dong Lu and Tong Zhou “Research on CSRF Attack and Defense Methods [J]” Electronic World vol. 12 pp. 139-140 2017.
9.Xinxin Zheng Research on CSRF Attack and Defense Technology [D] Beijing University of Posts and Telecommunications 2016.
10.Yingjun Wang Jianming Fu and Lily Jiang “Cross-site request forgery defense method based on randomized parameter names [J]” Computer Engineering vol. 44 no. 11 pp. 158-164 2018.
11.Haiyang Wei “Analysis of Information Security Application of Hybrid Encryption Technology in Network Communication [J]” Information Communication vol. 07 pp. 181-182 2018.
12.Pingping Shao “Research on Hybrid Encryption Technology in Computer Network Security [J]” Information Technology and Informatization vol. 12 pp. 123-125 2018.