websockets 安全与否? [英] are websockets secure or not?

查看:15
本文介绍了websockets 安全与否?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

wikipedia 似乎推断 websockets 是安全的:

<块引用>为了支持 Web 浏览器,在 Firefox 6(名为 MozWebSocket)、[2] Google Chrome 14[3] 和 Internet Explorer 10 开发者预览版中实现了 WebSocket 协议的安全版本....虽然没有已知的漏洞利用,但它在 Firefox 4 和 5 中被禁用...

但是 w3 表示它们不安全:

<块引用>遵循此处的 HTTP 过程可能会在 Web 浏览器上下文中引入严重的安全问题.例如,考虑一个主机在一个路径上有一个 WebSocket 服务器,在另一个路径上有一个开放的 HTTP 重定向器.突然之间,任何可以被赋予特定 WebSocket URL 的脚本都可能被诱骗与 Internet 上的任何主机通信(并可能与其共享机密),即使该脚本检查 URL 具有正确的主机名.

  1. http websockets (ws:) 是否安全?

  2. https websockets (wss:) 是否安全?

  3. 如果不是 #2,是否有记录在案的预防措施?

解决方案

WebSocket 安全有很多不同的方面.

您引用的维基百科的片段是指 WebSocket 客户端到服务器数据的屏蔽.这是为了防止行为不端的中介(例如代理和缓存)不小心将 WebSocket 流量解释为正常的 HTTP 流量.这里的危险在于 WebSockets 协议可用于毒害缓存中介.但是,我应该指出,这纯粹是理论上的问题,但 Mozilla 和 Opera 不愿意发布 WebSocket 协议的 Hixie 和早期 HyBi 版本,这足以引起人们的关注.因此,IETF 决定将客户端添加到服务器屏蔽数据以解决该问题.

顺便说一句,IETF 负责 WebSocket 协议 (IETF 6455),而 W3C 负责 HTML5 WebSocket API(Javascript 对象、方法和事件).

WebSocket 安全性的另一个方面是跨域安全性.您从 W3C WebSocket API 规范中引用的第二个片段与跨域安全性有关.WebSockets 支持跨域连接(到提供 HTML 页面的不同主机).这个警告是说如果正常的 HTTP 跨域程序被用于 WebSockets,这将打开一个巨大的安全漏洞.然而,正是因为这个原因,WebSocket 过程是不同的.一方面,WebSocket 握手和响应的设计使得 WebSocket 连接无法与不支持 WebSocket 连接的 HTTP 服务器建立:服务器必须以 WebSocket 特定方式签署/散列密钥,并在握手响应中返回它.第二部分是浏览器必须发送一个 Origin 标头作为握手的一部分(这表明 HTML/Javascript 最初是从哪里加载的).这允许服务器选择允许哪些域发起 WebSocket 连接.

最后,WebSocket 连接方式有两种:未加密(ws://)和加密(wss://).加密模式使用 TLS/SSL 加密来加密所有发送到服务器和从服务器发送的数据(包括初始握手和响应).这与用于 HTTPS 连接的加密机制相同(并在浏览器中使用相同的加密引擎).这可以防止第三方窥探正在传输的数据.

实际上只有两个版本的 WebSocket 协议值得了解:

  • Hixie76:此版本的协议添加了跨域安全性和标头散列/签名.但是,由于协议的设计方式,很难将其支持添加到现有的 Web 服务器.这是 iOS 目前支持的版本(希望 iOS 6 最终会更新到 IETF 6455)

  • IETF 6455:这是 IETF 去年 11 月(2011 年 11 月)标准化的 WebSocket 协议版本.这是 IETF HyBi 工作组工作的高潮(导致它的协议迭代被标记为 HyBi XX).这是当前版本的 Chrome 和 Firefox 以及 IE 10 和即将推出的 Opera 支持的版本.

wikipedia appears to infers websockets are secure:

For web browser support, a secure version of the WebSocket protocol is implemented in Firefox 6 (named MozWebSocket),[2] Google Chrome 14[3] and Internet Explorer 10 developer preview. ... Although there are no known exploits, it was disabled in Firefox 4 and 5...

but w3 states they are insecure:

Following HTTP procedures here could introduce serious security problems in a Web browser context. For example, consider a host with a WebSocket server at one path and an open HTTP redirector at another. Suddenly, any script that can be given a particular WebSocket URL can be tricked into communicating to (and potentially sharing secrets with) any host on the Internet, even if the script checks that the URL has the right hostname.

  1. are http websockets (ws:) secure or not?

  2. are https websockets (wss:) secure or not?

  3. if not #2, are there documented prophylactic measures?

解决方案

There are a lot of different aspects to WebSocket security.

The snippit from wikipedia that you quoted is referring to the masking of WebSocket client to server data. This is to protect misbehaving intermediaries (e.g. proxies and caches) from accidentally interpreting WebSocket traffic as normal HTTP traffic. The danger here is that the WebSockets protocol could be used to poison the caching intermediary. However, I should note that this was a purely theoretical concern, but it was enough of a concern that Mozilla and Opera were reluctant to ship the Hixie and early HyBi versions of the WebSocket protocol. So the IETF decided to add client to server masking of the data to address the concern.

As an aside, the IETF is responsible for the WebSocket protocol (IETF 6455) while the W3C is responsible for the HTML5 WebSocket API (the Javascript object, methods and events).

Another aspect to WebSocket security is cross-origin security. The second snippit you quoted from the W3C WebSocket API spec is related to cross-origin security. WebSockets support cross-origin connections (to a different host that the HTML page was served from). This warning is saying that if normal HTTP cross-origin procedures had been used for WebSockets, this would open up a huge security hole. However, the WebSocket procedure is different for exactly this reason. For one thing, the WebSocket handshake and response is designed so that WebSocket connections cannot be made to an HTTP server that does not support WebSocket connections: the server must sign/hash a key in a WebSocket specific way and return this in the handshake response. The second part is that the browser must send an Origin header as part of the handshake (this indicates where the HTML/Javascript was loaded from originally). This allows the server to choose which domains it will allow to originate WebSocket connections.

Finally, there are two WebSocket connection modes: unencrypted (ws://) and encrypted (wss://). The encrypted mode uses TLS/SSL encryption to encrypted all data sent to and from the server (including the initial handshake and response). This is the same encryption mechanism used for HTTPS connections (and uses the same encryption engine in the browser). This prevents third parties from snooping on the data being transferred.

There are really just two versions of the WebSocket protocol worth knowing about:

  • Hixie76: This version of the protocol added cross-origin security and header hashing/signing. However, due to the way the protocol is designed it is difficult to add support for it to existing web servers. This is the version currently support in iOS (hopefully iOS 6 will finally update to IETF 6455)

  • IETF 6455: This is the version of the WebSocket protocol that was standardized by the IETF last November (Nov 2011). It was the culmination of work by the IETF HyBi working group (iterations of the protocol leading up to it were labelled HyBi XX). This is the version supported by current versions of Chrome and Firefox and also by IE 10 and soon Opera.

这篇关于websockets 安全与否?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆