HTML5(WebSockets) 的脆弱性?

尽管还不是官方的标准， HTML5 的使用和影响力成长迅速。 无论是 Web 、移动、或甚至 SOA ，似乎都有一个 HTML5 的整合战略。然而，HTML5 不仅仅是一个原有的标记语言的更新，因为它包含了其他方面如 JavaScript 和 WebSockets 。最近我们已经听到了很多WebSockets 有关的内容，包含技术的引进和是否有任何对于REST 的影响。然而，近期 Lori Macvittie 辩论说 WebSockets 可能会导致一个不太安全的网站，如果人们以安全换取性能的话。 她从 2011 年的一份报告指出，很多人都已经习惯于这样做，并且已经有一个调查发现了这类情况…

…而 91％的受访者不仅在安全性和性能之间的进行权衡，实际上整整 81％是禁用安全功能的特性。

但是这个和 WebSockets 什么关系呢？Lori 认为是因为 WebSockets 删除了 HTTP 头，暴露了病毒和恶意软件扫描需要的漏洞：

你知道，像 content-type 的东西；你也知道，header 告诉终端正在传输什么样的内容，如 text/html 和 video/avi。反病毒和恶意软件扫描解决方案非常擅长特定类型内容的检测异常。问题是，在没有 MIME 类型的情况下，能够正确识别一个给定的对象变得有点难以确定。

当然，依赖于 HTTP 头不能保证避免恶意内容，但 Lori 提到：

[…] 一般来说，服务数据的应用对数据类型是不会撒谎的。很少会有恶意代码去利用这方面的弱点。毕竟恶意代码的目的是用一个指定的媒介传递恶意负载，这才是利用漏洞的基本原则—让系统针对恶意负载执行一套特定的指令。这意味着你真的需要终端相信内容就是如它所认为的那种类型。

Lori 接着说可扩展性方面的 WebSockets(子协议扩展)，它允许额外的有线格式和协议来定义，通过阻止防火墙来缓解问题而产生更多的问题：

[…] 没有办法肯定地知道什么正在通过 WebSocket 传递，除非你使用它的语言“说话”。这一切混乱的结果是，设计的安全软件扫的描特定类型内容不能为特定的签名或异常。他们不能提取通过 WebSocket 的传送对象、因为没有迹象表明什么地方开始或结束，甚至它是什么。如果在传送过程中 HTTP 头里的数据丢失，这包括类型与长度，那将给任何使用这些数据来解压或者处理相应数据的软硬件带来问题。

之前已经有了关于 WebSocket 的实现和协议的安全漏洞的报告， 就像过去几年有与其他 Web 协议的报告一样。当然，分布式系统的安全性比 HTML 早了几十年， 尤其是二进制协议。所以让二进制系统安全是有可能的，但 Lori 的观点似乎是，虽然我们要朝着更高性能的 Web 方向努力，但我们不应该忽视的事实是，绝大多数的 Web 基础架构是基于 HTTP 的，这不是轻易地删除或更换就可以的，事情总会因为各种原因出问题，甚至更糟。既然采用 WebSockets 似乎是不可避免的， 那现在是时候后退一步去考虑基于 WebSockets 的世界应该是什么样的的，至少从安全的角度来说。