择要：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.
