WebSocket为web应用和服务提供了双向实时通信信道，这篇论文概述了Websocket协议和这个API，并且描述了它提供的便利。本文的主要贡献是回顾和分析了与WS相关的安全问题，讨论了可能的解决方法以及部署WS的最佳实践。同样，这篇论文提出了在web浏览器中应该有一些安全的特性去余额宝用户的安全。浏览器供应商在提供安全特性方面充当着重要角色。WS至今还没有标准化，但是WS的利用会在近几年飞速发展，总的来说，WS解决了通信问题，但不是安全问题，一些开放的问题存在，但是如果有好的设计和好的浏览器和服务器的实现，这些风险将会降低。
KEYWORDS:websocket,html5 security,browser security,javascript,web
介绍
WS是一个在TCP协议上提供了双向实时通信信道,涵盖了JS API。虽然已经从HTML5独立出来，但是WS API经常被认为是HTML5 WS API[17]。虽然WSAPI在2012年就已经出现，但是到现在还没有确立，但是已经有许多不同的Web浏览器已经开始利用了。
WS协议是一个运行在TCP上的网络协议，它是实施在Web浏览器和Web服务器之间的，当然也可以被用在其他方面。WS协议是独立于HTTP协议的，虽然他们有相似之处，比如在初始化链接时，用的都是TCP80端口以及握手过程。由于WS协议被认为在未来几年里会影响web通信。所以也会影响到web安全，WS仍然是一个相对新的构想，没有非常多的针对于WS安全的研究，本文主要针对的是在WS协议其API和可能发生的安全问题，以及该技术所提供的安全特性。
本文的结构如下，第二章主要讲了WS技术的背景已经JS API的利用。第三章主要讲了WS的安全隐患，第四章讨论并且分析了安全问题和解决方法，第五章提出了新的一些解决方案。最后一章总结了全文，以及未来的工作。
2 背景
这一章节回顾了WS更多的一些技术，2.1讨论了与之前传统通信技术相比，ws新的特性以及优点。2.2说明了WS JS API在客户端的利用。
2.1 WS 特性以及优点
与传统的建立在HTTP之上的网络通信相比，WS最大的不同是不遵循传统的请求——应答通信方式。当客户端和服务端开启了一个WS 通信，两方都可以实时异步的发送消息给对方。这个连接保持打开并活跃直到
有一方断开连接。
相反的，传统方式依赖于轮询，也就是客户端打开一个新的TCP连接，建立一个HTTP请求去向服务端接收数据。这个需要在客户端和服务端在任何信息被发送之前有几个来回的轮训。当有任何分块的消息传送时，客户端又需要建立一个新的请求。因此，对比WS，传统的HTTP请求应答通信会导致延迟以及网络拥堵，图一说明了WS与HTTP的区别。
WS协议的低冗余意味着处理和解析数据需要更少的计算资源了，而且较低的延迟可以让用户有更好的体验。然而，从客户端的角度来看，WS协议的优势以来于用例？如果只是一些小数据的传送，那么WS的优势便不会很明显，因为通信量开销对于实际有效载荷数据是微不足道的？
从另一个方面来讲，当定时地提供少量的数据，WS协议可以减少总网络流量，总的来说，与传统HTTP请求应答通信形势，WS协议可以减少500：1的网络流量和3:1的网络延时。一个研究显示，HTTP延时是WS的2.3-4.5倍。
2.2 ws功能
客户端通过给服务端发送一个特殊的HTTP请求，这个请求是对现有的通信进行升级，从而建立了一个ws通道。当服务端接收了这个请求，当前的消息传输便会使用WS协议。
WS API通过js还可以被用于web应用中,类似于XML.
（上述便是一个WS API ）
在上述列表中我们可以定义需要进行对话的远程服务以及TCP的端口。API会负责握手以及协议的升级。然后，我们可以分配（在发生任何动作时叫唤？）的回调函数，当一个连接已经建立，我们可以发送数据给接受者或者关闭这个连接。这在表2说明：
3.Websocket的安全问题
在Web安全中，安全主要依赖于TLS（Transport Layer Security）加密，以及浏览器上的同源策略。总的来讲，TLS加密提供了一个安全的交流通道，而同源策略避免了恶意的夸张威胁。
然而，ws协议在很多方面与HTTP不同，这些不同也许会对web安全造成威胁，甚至是非常不明显的。例如，WS消息不包括HTTP头，这可能会影响网络代理和防火墙的行为。WS的origin policy也与HTTP不同，同样的，一些潜在的威胁也会影响WS技术，下面会详细降到。
3.1 origin policy
WSAPI 让web应用可以建立连接向任何一个服务器发送数据[4]。对于web应用开发者来说，当在不同的服务分享资源时，这是非常方便灵活的。与HTTP进行对比，WS协议利用了verified-origin机制。这种机制让目标服务器来决定哪个源是允许进行连接的。WS框架是不包括HTTP头的，因此，源主机只会给服务器发送一个升级请求，这个请求不是正常的HTTP请求。那么检查源主机、接受或者拒绝这个连接的责任就到了服务提供者身上。由于源可以被轻易的仿造，这个verified-origin策略并不阻止任何一个发送过来的请求。所以，这个策略可以避免客户端遭受CSFR攻击？。
3.2 代理和防火墙
代理和防火墙曾经被考虑在WS协议的计划原则中，握手过程是和HTTP兼容的，而且HTTP标准的80端口也被用于WS协议。然而，知道问题的存在，特别是在代理遍历通过透明的代理[1,8]?在2010年一个WS协议的弱点便被报道了。恶意利用WS通道使一些透明的web代理缓存中毒。一些浏览器供应商废弃了WS直到WS工作小组引进了来防止这些漏洞[4,5]。由于WS框架内容递交的不是存文本Frame-maksking保护了WS客户端和服务器，防止在其网络中间人注入恶意内容。在实践中，frame-masking是一个32Bit随机数，在每一个框架的开头？通过字节n，以及字节n mod4用XOR?(反正就是一种遮蔽方法)。
WSzhen中缺少HTTP的头可能会成为一个问题。先进的防火墙和恶意软件检测工具是通过协议和数据类型来分类和处理数据的，它们可能不会意识到WS协议。自从WS协议通过frame-masking来防止代理缓存中毒，这也会阻止防火墙和反病毒工具去分析数据模式和检测恶意内容[13]。缺乏元数据，比如HTTP头，使得分析WS帧更加困难。
（大概意思就是利用WS可以使防火墙离线缓存中毒，然后就想了一个frame-masking的办法去保护，但是这个也会让防火墙不好分析数据以及恶意内容）
WS协议没有指定有效载荷数据的格式，因此，开发者可以在通过WS通信时指定一个传统的协议或者使用现有的应用层协议。然而，WS指定一个头“Sec-WebSocket-Protocol”，这可以被用在握手过程中去声明这个应用程序协议用的是WS协议。这个使得防火墙和路由器去设置安全策略，这些策略可以让其意识到这是WS协议。然而，恶意内容可以通过WS来绕过防火墙和反病毒工具，去损害终端用户。
（上面说到WS是不包括HTTP头的，这样就可以影响防火墙的行为，Client和Malicious Sevice之间的WS通信可能不会被防火墙屏蔽。然后M就可以通过一个WS client进入内网）
3.3 恶意服务
一个恶意网站可以很容易的建立一个远程shell去访问受害者的浏览器，当攻击者能够在web浏览器上运行任意的JS code，那么他也能够对任意的服务器发起一个WS连接。在这之后，攻击者可以利用现有的WS通道去控制web浏览器[14]。
WS API 不仅允许请求到任意的一个主机，而且任意的TCP端口。因此，这个技术可以被用来进行受害者内网的端口扫描以及网络mapping[15]。这个可以利用时间分析，也就是，观察从发起一个WS握手连接开始到服务器返回的时间。例如，如果远程服务器正在监听一个TCP端口，WS连接尝试去对其进行一个TCP握手，由于TCP握手需要两个来回，Web应用便会根据时间响应来五分开放的或者关闭的端口。[6]
因此，攻击者可以绕过防火墙，他可以通过设置受害者的浏览器，把受害者的浏览器当成一个在攻击者和内网之间的WS代理。（例图2）这个工具也已经有了是JS-RECON。
另一个通常的攻击便是Dos。客户端和服务器充斥着数据或连接请求到达了终端无法处理所有的请求这个地步。这个会导致服务不可用或者应用程序的奔溃。另外，通过劫持大量的web客户端，攻击者可以利用WS实现一个分布式拒绝服务攻击。由于ws通信极限是比较高的，–在浏览器之间能达到900-3000,WS会成为一个强大的技术。
这些所有的攻击需要受害者访问恶意网站，或者在一些好的网站里注入恶意代码。这是可以实现的，比如，利用XSS。
3.4 XSS
Xss 是web应用的一种很常见的安全问题。攻击者可以利用XSS漏洞在一些可以被用户修改参数和变量的网页中注入恶意代码。例如，下列代码反应了XSS，这个可以被JS注入或者是HTML代码IN GET参数name中。
XSS在web中非常常见，它们的存在并不取决于是否用了WS。因此，许多类型的web服务中都包括了XSS漏洞，并且有好几种方法可以通过XSS去攻击用户。
然而，利用了WS的网页中，XSS有了一些新的威胁，例如，利用XSS，攻击者可以重载一个WS连接自定义的回调函数，这可以使攻击者去嗅探网络流量，操纵数据，或者实现一个WS连接的中间人攻击。另外，利用XSS漏洞，攻击者可以实现3.3中描述的任何攻击。
3.5加密和数据验证
WS协议没有指定认证身份或者加密连接的机构。协议支持TLS去提供一个值得信赖的连接通道，因此，TLS提供了传输从的加密，并且提供了值得信赖和完整的WS帧。身份的认证也可以利用TLS或者其他一般的web认证来解决，例如cookie或者HTTP认证。
另一个相关的点是数据的有效性，WS协议指定客户端和服务器端在接收到双方数据的同时来验证这个数据，如果到达的数据是无效的，那么WS连接将会被关闭。通常来讲，WS服务器应该一直假设客户端是不会遵循WS协议的，源也是会被篡改的。
3.6缺乏官方的标准
另外的问题是由于没有完善的官方标准以及早期实现的WS API，例如，WS协议定义了加密的WS连接只能建立在TLS安全的网站上，然而，只有Mozilla Firefox能实现。
由于标准还没有完善，API和协议仍然会改变，WS在防火墙，网络分析工具和代理中也会慢慢适应。所以，在利用WS部署一个服务时，符合最新的规范是非常重要的。
4 分析和讨论
WS提供了许多便利，也有了很多新问题，有一些是理论上的，所以需要进一步去学习才能更好的理解。从另一个方面来讲，有一些安全问题是显而易见的并且也有了概念性的验证。本文中讲到的很多攻击不仅仅只是针对WS API以及WS协议。比如，许多协议，任何网络层都可以有Dos攻击，WS只是其中一种协议。
不是所有的安全问题都是源于WS协议，这些问题与平时所用的网络工具也有关，比如代理和防火墙等，这些工具是不了解WS协议的，就如同浏览器是不理解协议规则和安全策略的，这种状态是会慢慢改变的，知道WS协议被标准化。
总的来说，WS在实时通信上提供了许多便利，但是安全问题不容忽视。我们在考虑WS技术的安全问题可以分为两个部分
1. 在值得信赖的网站上发展WS技术，保护服务的安全及用户的隐私。
2. 保护浏览器和终端用户免受恶意利用WS带来的安全问题
解决第一个问题的方法在4.1,总的来说，TLS加密提供为多数服务了一个安全的态。然而第二个问题比较复杂，问题就在于如何判断网站利用了WS技术，如果这个网站或者这个服务是可疑的，浏览器会关闭这个WS连接，并且提醒用户，取决于安全策略，我们在4.2分析。
4.1 部署建议
开发者需要考虑安全服务的后端，例如服务器和数据库，也要考虑用户的隐私。下面是一些安全建议，是在”html5 security cheat sheet”基础上做的。
1. 按照规则部署
2. 开发者需要注意XSS
3. 为了实现机密性和完整性，还是需要用到TLS加密，如果一个网站是创建了一个WS连接，TLS还是需要利用到。
4. 着重注意身份验证和会话管理
5. 端点不能够互相信任，客户端和服务器需要验证所都通过WS发来的数据。
如果可以的话，利用已经存在的并且广为人知的办法去实现WS服务的一个部分，例如，利用一个公共的应用层协议作为WS连接的一个子协议，毕竟创建一个新的协议需要很大量的知识。
4.2 分析可能的解决方案
保护终端用户不瘦恶意网站，一个解决方案是在建立WS连接时始终需要获得用户的允许，让用户去决定这个连接是否可信。但是，大部分人是不了解这个协议的。只会一味的去选择同一。并且，WS如果充分被利用，一直请求是不现实的。
另一个可能的解决方案是在浏览器上装入侵检测系统，浏览器会保持WS连接的一个列表，根据连接的目的地主机和端口，去检测恶意的活动，比如扫描端口或者网络分析。例如，浏览器可以检测，关闭企图连接到subsequent IP地址和网络端口的WS连接。这是可以被实现的，很多防火墙有这个功能，虽然实现的不太好。然而，防火墙经常可以保护网络免受外网连接，WS可以进行内网扫描。
根据3，3已知，端口扫描是根据时间响应。因此，强迫一个小的延时可以阻碍端口扫描，这可以阻碍分析打开或者关闭的端口。然后这是一个表现和安全的权衡问题。
为了保护用户免受DOS攻击，我们需要限制连接数和消息最大尺寸。很多浏览器已经限制同时的WS连接{13}.协议指定了单个WS消息需要包括无限的帧，所以帧的大小是无限的{5}。另外，底层实现的时候需要把零碎的消息结合给上层一个完整的消息。因此，如果问题没有被正确处理，客户端和服务器可能会耗尽内存。
防止到浏览器的远程shell是有问题的，由于JS是动态的，动态检测分析脚本注入是几乎不可能的。然而，数据可以被自定义，同样的，WSAPI不用JS的eval函数也是不正确的，因为恶意代码可以被事先写在网页里，被WS连接唤醒。
4.3解决办法
浏览器供应起很大作用，在实践中，可以分析网站元数据和WS连接。以下是一些合法性考察
1、 大量数量的WS连接
2、 WS连接企图连接IP地址和端口
3、 WS连接企图连接可疑的目的地，例如本机或者内网
4、 源主机出现在黑名单或者白名单服务里？
5、 其他异常的WS连接，比如超长的WS消息或者帧、
监控这些指标不需要分析网站源代码。
例如，一个公共的网站，不出现在任何白名单服务中，企图向内网一个IP地址建立一个WS连接，这就可以被视为是可疑的。如果一个网站出现在白名单服务中，那就可以同意使用WS。在很多情况下，这是很难去判断的，所以需要浏览器去提醒用户。
前面提到过用一个小的延时去组织网络扫描，限制WS连接数量以及限制WS帧大小可以阻止DOS攻击。
WS可以安全的创立，但是恶意的网站还是会故意利用WS去攻击终端用户，还有一些没有解决的问题比如JS shell,我们需要适当的实现和优化，这样的特性可以增强浏览器的安全。
5 总结
通过此文，WS技术提升了实时通信技术，但这个技术还没有完全成熟，虽然对HTML5以及相关技术的期望很高，我们还没有看到最后的突破。我们期望WS可以全面应用，特别是对时间要求很严格的web应用和服务中。
一旦WS技术被全面应用，安全问题将受到极大关注。虽然WS服务部署的十分安全，但是它们还是可以被用于恶意的地方。所有人都应该关注这些问题。限制WS API在浏览器上的应用是比较合理的。
作者：terry，如若转载，请注明出处：https://www.web176.com/websockets/651.html
