Firefox 4 中已禁用 WebSocket

最近发现，WebSocket 工作的协议存在安全漏洞。Adam Barth 演示了一些针对该协议的严重攻击，攻击者可以利用这些攻击来中毒浏览器与互联网之间的缓存。

这是一个对互联网和 WebSocket 构成严重威胁的问题，它不是特定于浏览器的。该协议漏洞还会影响 Java 和 Flash 解决方案。在 Web 环境中，这可能意味着，例如，广泛使用的 JavaScript 文件（如 Google Analytics）可能会被替换为缓存中的恶意软件文件。Google 不会对此负责，而且您也很难追踪该文件的来源，因为它不在您的服务器上。为了避免大量恶意软件无法追踪地出现，我们需要修复该协议。

Firefox 4 和 Opera 中不支持 WebSocket，直到修复安全问题为止

因此，我们决定从 Beta 8 开始在 Firefox 4 中禁用对 WebSocket 的支持，这是由于协议级的安全问题。Firefox 的 Beta 7 版本支持 -76 版本的协议，该版本与 Chrome 和 Safari 中包含的版本相同。Firefox 4 的 Beta 8 版本将删除该支持。Opera 的 Anne van Kesteren 也宣布 Opera 将取消对 WebSocket 的支持。我们相信其他浏览器开发人员会效仿。

这对开发者来说意味着什么？

现在，您的 WebSocket 解决方案在 Firefox 4 正式版中无法运行。一旦我们拥有一个我们认为安全且稳定的协议版本，我们将在 Firefox 的某个版本中包含它——甚至是在次要更新版本中。该代码将保留在树中以帮助开发，但只有在开发者在 Firefox 中设置隐藏的首选项时才会被激活（Opera 也是如此）。

如果您的代码执行了正确的对象检测，则不会出现任何问题——当用户未启用 WebSocket 时，window.WebSocket 属性将不可用。

正在修复中

Mozilla 仍然对 WebSocket 提供的功能感到兴奋，我们正在与 IETF 共同努力开发新的 WebSocket 协议。

现在，我们正在突破浏览器为用户提供功能的界限——这就是 HTML5 的意义所在。

在推动任何技术的界限时，您都会遇到问题。我们现在遇到的好消息是，我们可以对出现的任何问题做出迅速而有效的反应，并在最终用户受到影响之前修复它们。让全世界升级并修补最终版的浏览器几乎是不可能的，因此，在 Beta 版和夜间版中进行测试和修补是有意义的。

HTML5 和开放 Web 的倡导者。让我们来修复它！

Chris Heilmann 的更多文章……

47 条评论

Matt Ranney

这听起来是一个非常严重的问题。您是否也应该禁用 Java 和 Flash？

2010 年 12 月 8 日下午 6:00
1. John Haugeland
  
  不会。Flash 和 Java 设计精良，不会受到这种攻击的影响。
  
  安全不应该依赖于猜测。
  
  2010 年 12 月 8 日下午 7:19
2. WulfTheSaxon
  
  我认为，指的是 Flash 或 Java 对 WebSockets 的实现会很脆弱，因为这是规范本身的漏洞，而不是任何一种实现（如 CSS 历史嗅探或最近的 JavaScript 漏洞）。
  
  2010 年 12 月 9 日上午 12:20
  1. Henri Sivonen
    
    根据该论文，无论是否存在 Web Socket，都可以在 Java 和 Flash Applet 中对易受攻击的透明代理发动攻击。
    
    很想知道 Adobe 和 Oracle 以及透明代理供应商将如何应对论文中提出的发现。
    
    请注意，如果您在易受攻击的透明代理后面，而另一个在同一代理后面的人运行可以用来中毒代理缓存的软件，那么您就有可能从中毒的缓存中获取错误数据（据我理解论文）。因此，最好的防御措施是使用不强制您使用透明代理的 ISP。
    
    2010 年 12 月 9 日上午 2:47
    1. Billy
      
      >因此，最好的防御措施是使用不强制您使用透明代理的 ISP。
      
      嗯，是的，谢谢，这是一个很好的解决方案。
      
      – 您的 ISP 甚至不会告诉您它是否使用了一个。
      – 您的 ISP 可能会拒绝回答您的询问。
      – 消费者没有自由选择权，因为存在 Comcast 这样的 ISP 垄断。如果您想在我的区域使用有线互联网，他们就是唯一的选项，而且他们积极地反对自由选择权。
      
      这很不合理，说有人应该切换到速度慢、延迟高的卫星互联网或无法使用的 DSL（如果您离得太远，或者您有报警系统，或者您的线路上有太多爆裂声，或者当天行星没有对齐，您就无法使用它），仅仅因为一些普通人从未听说过的特定安全漏洞，即使他们听到了，他们也不理解。
      
      2010 年 12 月 16 日下午 2:29
Sasha Aickin

可以认为，这是

2010 年 12 月 8 日下午 9:38
Sasha Aickin

可以认为，这是一个透明代理实现中的漏洞，而不是 WebSocket 协议本身的漏洞，对吧？

此外，Matt 的观点非常有道理。如果您出于这个原因禁用了 WebSockets，为什么不也禁用 Flash 和 Java 呢？无论是在 FF4 中还是在已发布的 FF 中。它们和 WebSockets 一样容易受到攻击，似乎是。

2010 年 12 月 8 日下午 9:41
Kyle K

请纠正我，如果我对攻击载体有误解，但这与 WebSockets 的漏洞无关，而与透明代理和盲目信任流经它们的数据的目标系统有关。

攻击场景

1) 浏览器通过代理访问 malicious.com

2) malicious.com 返回一个 SWF

3) 浏览器运行 SWF，并从 malicious.com 检索一个策略文件，该文件声明您可以打开到任何地方的套接字。

4) 浏览器允许 SWF 通过代理打开到 malicious.com 的套接字，该套接字以与最初的 HTTP 请求相同的 URL 和端口为目标。

5) SWF 将字节发送到 malicious.com，这些字节通过代理，并且这些字节恰好是有效的（但伪造的）HTTP。伪造的 HTTP 具有 target.com 的 HOST 标头。

6) 代理读取字节，并将伪造的 HTTP 请求盲目路由到 target.com，请求“秘密”数据。

失败代理没有验证 target.com 的伪造 HOST 是否与最初请求的 HOST（导致该套接字（保持活动状态，现在被重新使用？？？）最初打开）匹配，它仍然假设它用于 HTTP，而不是其他协议。

失败代理没有采取任何措施来验证 HOST 标头中的 URL 是否通过 DNS 解析为一致的 IP 地址。

7) target.com 从代理服务器接收对“秘密”文档的 HTTP 请求，并回复代理数据，然后数据被发送回浏览器，随后变为 malicious.com 的 SWF 可用。

失败 target.com 假设来自代理的具有 target.com HOST 标头的 HTTP 请求是经过身份验证的，而没有检查会话 Cookie 或密码以确定身份验证和授权。

这怎么能说是 Java、Flash 或 WebSockets 的错误呢？

攻击场景

1) 访问 malicious.com，接收脚本，该脚本向 malicious.com 提交 POST，该 POST 实际上请求 WebSocket 升级。

2) 代理忽略 WebSocket 升级请求，但将响应从 malicious.com 传回，因此保持套接字连接处于活动状态。

3) 浏览器通过 WebSocket 向代理服务器发送字节，这些字节被伪造（但有效）的 HTTP 请求目标为 HOST target.com，并请求一些流行的 javascript 文件。

4) 代理服务器不知道 WebSocket，认为它只是一个普通的 HTTP 请求，因此将请求传递给 malicious.com（尽管 HOST 头部指定了 target.com）。

5) malicious.com 返回恶意 javascript 代码。

6) 代理服务器假设响应来自 HOST target.com 而不是 malicious.com（啊？参见步骤 4），并将恶意 javascript 代码存储在其针对 target.com 的缓存中。

7) 恶意 javascript 代码会被提供给任何通过该代理服务器请求该资源的 target.com 用户。

失败，这是什么鬼？无言以对…

再说一次…这是 WebSocket 的错吗？

2010 年 12 月 8 日下午 9:54
1. Unni V Mana
  
  Kyle，我同意你的观点。这不是 WebSocket 的问题。因为 FF 已经注意到这个问题，并且正在努力克服这种环境下的脆弱性，以便在任何糟糕的环境中，WebSocket 的实现都不受影响。如果存在问题，则问题是由于 TCP 引起的，因为它允许套接字连接，而 WebSocket 直接通过 TCP 工作（根据 WebSocket 规范）。
  
  2011 年 1 月 3 日下午 10:30
Marco Pivetta

太可惜了 :(
我一直期待着 WebSocket，现在我所有的使用它的项目都必须停止或迁移到 HTTP 轮询或类似的“脏”解决方案…
我希望 Mozilla 和 IETF 能够尽快准备好新的规范：WebSocket 是 web 开发中最重要的改变之一，因为它可以让任何类型的应用程序在浏览器上运行（在我的情况下是 FPS 游戏和一般游戏）…

点赞，伙计们，继续努力！:)

2010 年 12 月 9 日上午 1:08
wdu

这到底是如何解决论文中描述的安全问题的？那些有漏洞的代理服务器是有漏洞的，无论 Mozilla 做什么，它们都会保持脆弱。

你也可以停止所有 Mozilla 的新版本发布。这也不能解决问题 :-)

2010 年 12 月 9 日上午 2:42
Ruud Poutsma

是否可以默认情况下为每个网站关闭它，但可以选择性地为可信网站开启它？
这样我们就可以继续推广它，但保持 web 的安全性（或不安全）与现在一样。

2010 年 12 月 9 日上午 3:17
1. lapc506
  
  但是，它可能成为一个安全漏洞，一个从安全的可信网站（例如 Google，Google 在 HTTPS 中用于 Gmail 的网站）窃取的证书可以用来“打开首选项”，FF 认为它是安全的，修改后的证书允许通过 WebSocket 从恶意网站访问“恶意代码”，而你却认为你还在使用 HTTPS。如果修改后的证书包含 JavaScript 中的特殊代码，例如“保持 WebSocket 打开”（即使在关闭时，FF 也会保存此首选项），这应该是一个大问题，不是吗？
  
  2011 年 1 月 8 日上午 10:04
  1. Montana
    
    更重要的是，为什么 Firefox 不让我们决定是否要启用 WebSocket？
    
    哦，还有一个想法：为什么不为安全证书创建一个公钥系统？然后 FF 可能能够检测到被盗的证书。
    
    2011 年 2 月 7 日上午 7:06
  2. Michael C.
    
    你的整个场景从一开始就搞错了，因为那不是证书的运作方式。你不仅需要证书（任何人都可以从任何网站获取证书，因为它公开），而且最重要的是，还需要证书的私钥。其次，你只能从证书中指定的域名（或子域名）提供证书，所以你还必须执行 DNS 欺骗。第三，你不能在证书中包含 JavaScript 代码（或者，即使你能够通过某种辅助扩展来包含，它也是没有意义的）。
    
    2011 年 6 月 22 日下午 7:16
hmmm

不酷，伙计

2010 年 12 月 9 日上午 3:25
Danny Moules

非常遗憾，但我们非常感谢你们的快速反应！

2010 年 12 月 9 日上午 6:17
Mark Roggenkamp

为什么不将 WS 放在 SSL/TLS 之上。它们不是已经基本上使用相同的机制通过代理服务器了吗？

2010 年 12 月 9 日上午 6:39
Daniel Ennis

伙计们…

这是错误的举动。我真的希望 Mozilla 立即审查这个决定并撤销它。

阅读 PDF!!! 漏洞不在 WebSocket、Java 或 Flash 中。

漏洞在于代理服务器本身。

任何可以打开套接字连接的语言或平台都可以利用某些代理服务器的漏洞。

归根结底，WebSocket 连接的握手会让不安全的代理服务器感到困惑。这与 WebSocket 规范无关。

这么说，就是说任何具有类似 HTTP 的规范的“容易受到攻击”，这是非常不正确的。

错误在于代理服务器，关闭 WebSocket 不会解决此漏洞，只会关闭一种可能的实现。

我完全支持改变握手以使用 CONNECT 方法来缓解 WebSocket 被使用，但删除 WebSocket 支持是最糟糕的想法，因为这不是 WebSocket 的错。

Mozilla 请重新考虑，重新启用 WebSocket，但继续推动使用 CONNECT 改变规范。

仅仅因为可以利用另一个软件中的漏洞而删除对标准的支持是一个非常糟糕的决定。

按照这种逻辑，我们应该删除 AJAX，因为一些 HTTP 服务器可以被利用，或者删除 JavaScript 支持，因为一些插件可以被利用。

这没有道理。

请尽快撤销这个决定。这是一个可怕的错误。

2010 年 12 月 9 日上午 7:19
Martyn Loughran

虽然这是一个令人讨厌的挫折，但值得将其置于一个视角，指出这有望是暂时的。这不是 WebSocket 概念的根本缺陷，只是当前的__草案__规范暴露出来的问题。

更重要的是，这个问题是关于有缺陷的代理服务器，这些代理服务器已经可以被 Flash 和 Java 利用，理论上也可以被当前的 WebSocket 草案利用。

作为一家将 WebSocket 作为服务的公司，我们相信 WebSocket 将继续成为人们日常在线体验中非常核心的一部分。我在这篇博客文章中详细介绍了我们的想法

http://blog.pusherapp.com/2010/12/9/it-s-not-websockets-it-s-your-broken-proxy

2010 年 12 月 9 日上午 8:09
Jon Neal

Douglas Crockford 不是一年前就警告过 HTML5 中存在严重的安全漏洞吗？我不得不认为这是他所说的事情之一…

2010 年 12 月 9 日上午 8:23
qwe

你是认真的吗？

2010 年 12 月 9 日下午 2:04
dss

看起来 Firefox 和 Opera 团队的人完全疯了…
这次攻击针对的是有缺陷的代理服务器，而不是 WebSocket。
WebSocket 本身是安全的。
WebSocket 与代理服务器处理 HTTP 升级的方式有什么关系？
即使你在全世界范围内完全禁用 WebSocket，每个人都可以对你的代理服务器发动这种攻击，只需向它发送格式错误的 HTTP 请求即可。
禁止 WebSocket 是为了帮助修复所有这些糟糕的代理服务器吗？

2010 年 12 月 9 日下午 2:59
Yuri Agenni

这基本上总结了我对 WebSocket 的 2 分钟体验：http://www.xtranormal.com/watc…/

2010 年 12 月 9 日下午 5:16
ben porter

哦，不，这不是好消息。我参加 gameon 2010 的参赛作品使用了 WebSocket。

我希望评审委员会现在允许使用 Flash xmlsockets，因为 WebSocket 已经无法使用了..

2010 年 12 月 9 日下午 6:33
MRK

我们很幸运，在“Web4.0”（我们已经到了吗？）中有人在使用他们的能力和意识！无论大多数人是否将 cookie 保持打开并将其密码粘贴在显示器上，任何添加的“功能”，即使它是“可禁用的”，也可能损害安全性，不应该在没有提出 2 个问题的情况下“投入到大众手中”

首先，最恶意的攻击者如何使用可用的资源来利用这个新功能作恶？

其次，这个功能是否有利于那些期待高效、稳定和安全的应用程序的人，以及满足营销人员的需求，并取悦公众。

我很高兴至少有人问了其中一个问题。:)
MRK

2010 年 12 月 10 日上午 8:35
Ruhsen Kahraman

我在我的项目中使用 WebSocket，它运行良好，我不会使用其他解决方案。我相信开发人员会解决这个问题。WebSocket 将改变浏览器，从死的客户端到智能的实时控制台。

2010 年 12 月 11 日上午 3:09
jonathan Chetwynd

听起来有点不诚实，

开发人员的“隐藏首选项”是什么？

network.websockets.enabled 仍然设置为 true….

那么作为一名开发人员，我如何启用 WebSocket？

2010 年 12 月 12 日下午 2:29
Olav Kolbu

浏览到 about:config 并切换 network.websocket.override-security-block。

2010 年 12 月 14 日上午 7:01
TJ Vanderpoel

我只希望 Opera 和 Mozilla 的开发人员能诚实地说明漏洞_在哪里_。它与 WebSocket 本身无关，而是与代理 web 流量的软件和设备有关。有谁列出了有问题的设备和软件，并开始着手施压他们修复他们导致漏洞暴露的弱点（通过 WebSocket、Flash、Java、任何可以进行原始套接字的插件）？这似乎比禁用 WebSocket 并破坏应用程序支持（我们的 WebSocket 内部呼叫中心在用户从 FF4B7 升级到 B8 后停止工作）更好的方向。至少这给了我们从 FF 转换为 chromium 的弹药，不确定这是否是你们想要达成的目标。

2011 年 1 月 11 日下午 1:52
WulfTheSaxon

正如 Olav 在上面所说：“浏览到 about:config 并切换 network.websocket.override-security-block”。没必要切换到 Chrome。（不过，坦白地说，你无论如何都不应该在业务中使用预发布软件。）

2011 年 1 月 11 日下午 4:25
James B

最好的防御措施是*不要将 HTTP 用于套接字*。
只要给我们 Flash 风格的真实套接字，就足够了，如果主机想要允许 HTTP 请求，他们必须指定它。更安全*并且*更通用。

2011 年 1 月 23 日下午 12:38
1. James B
  
  我试图说 policy-file-request。结果是把它放在标签中会把它过滤掉。
  无论如何，policy-file-request 意味着 Flash 套接字只能在专门批准的服务器端口上使用。这确实是最好的方法。
  
  2011 年 1 月 23 日下午 12:40
Quizori

至少。我需要 127.0.0.1 允许。

2011 年 2 月 21 日上午 3:07
the future

巨大的错误。

我希望尽快得到修复….

2011 年 2 月 28 日下午 4:55
Zequez

Awwwww =(
Websockets 太棒了 =/
希望你很快就能找到安全实现它的方法 ^^
无论如何，这并不会阻止我继续做只有我能运行的超棒 HTML5 实验性应用 :P

2011 年 3 月 23 日下午 7:24
whatdoesitwant

有没有办法从命令行脚本化开启和关闭 websockets？我需要在开发过程中开启，其他时间关闭。一些适用于 Windows 的 shell 脚本就可以了。或者，如果我可以在同一系统上安装两个版本的 Firefox，我可以将其中一个限制在局域网内。
在 http://techdows.com/2010/12/turn-on-websockets-in-firefox-4.html 上描述的技术有点麻烦。
非常感谢您的任何提示。

2011 年 3 月 30 日上午 12:00
WulfTheSaxon

@whatdoesitwant: 从命令行运行“firefox.exe -p”将打开配置文件管理器，允许你创建新的配置文件。之后，“firefox.exe -p profileName”将打开特定的配置文件（在你的开发版本中添加 -no-remote，这样它就可以同时打开）。

不知道为什么 Firefox 默认情况下没有配置文件管理器的快捷方式（它在 Songbird 和一些其他的 XULRunner 应用中）。多年来，我在不同的目录中安装了稳定版和夜间版，并为它们创建了独立的配置文件。

2011 年 3 月 31 日上午 8:36
whatdoesitwant

@Wulf 谢谢，这有效。一开始我创建了 firefox.exe 的副本作为 firefoxdev.exe，以便 Windows 和我的防火墙将这些实例识别为独立的应用程序。但显然，像你建议的那样，在单独的目录中进行额外的安装更安全。另一方面，将 Firefox 实例限制在局域网内当然会阻止它更新。所以我使用第三方程序 Secunia PSI 来处理这个问题。

注意，我注意到 Chrome（10）默认情况下使用 websockets，尽管存在安全问题。希望这个问题能很快得到解决。

2011 年 4 月 1 日上午 7:30
1. Aikar
  
  @whatdoesitwant: 因为 Chrome 很聪明。
  
  Web Sockets 中不存在安全漏洞。
  
  WS 协议很好，Firefox、Chrome 和其他浏览器中的实现也很好。
  
  完全没有理由禁用 WebSockets。
  
  Mozilla 仍然没有意识到他们的错误，这真令人难过。
  
  2011 年 4 月 1 日下午 3:30
mc

那么为什么他们仍然没有开启它？WebSockets 在 Firefox 中的未来是什么？

2011 年 4 月 19 日下午 2:29
DAlDo

关于什么时候在 FireFox 中恢复 websockets 有什么消息吗？你能更新一下修复进度吗？
谢谢。

2011 年 4 月 23 日下午 3:35
Kristjan

是否可以通过 HTTPS 升级 websocket？它是否仍然容易受到代理问题的影响？

2011 年 5 月 10 日上午 6:22
José Angel Yánez

什么？

这太糟糕了，这不是 WebSockets 的问题，而是代理问题，任何人都可以通过任何类型的套接字利用这个问题，比如：Flash。

Kirk 你说得对……

2011 年 6 月 13 日下午 4:50
viktor

这个问题已经解决了，请不要再评论这个问题了！

2011 年 7 月 1 日上午 4:52
Tom

如果我们采取这种宿命论的态度，认为受影响的代理会永远存在，那么我们是否应该完全避免使用这个 80 端口？

为什么不在完全独立的端口上标准化类似 WebSockets 的协议呢？比如 40 端口。当然，一开始，许多使用严格代理的用户根本无法使用它，但没有访问权限总比不安全的访问权限好。

这个协议可以更简单，因为它不需要在 TCP 握手之上进行 HTTP 握手，也不需要考虑向后兼容性。

我们甚至可以为该协议提供一个补充的 UDP 版本，这将使网络语音通信成为可能，而无需 Flash。

2011 年 8 月 20 日上午 11:41
saga

这是一个糟糕的决定，许多依赖于 websocket 的项目可能会因此而被扼杀，想想那些使用 Firefox 4+ 的用户，他们将无法使用这项功能。

此外，Mozilla 发布了 Firefox 的 3 个版本，分别是 4、5 和 6，这将导致敏感的客户端需要更多的测试工作，开发团队只是在敷衍了事。

2011 年 8 月 31 日下午 2:42

本文的评论已关闭。

Hacks

作者 Chris Heilmann

Firefox 4 和 Opera 中不支持 WebSocket，直到修复安全问题为止

这对开发者来说意味着什么？

正在修复中

关于 Chris Heilmann

47 条评论

Firefox 4 中已禁用 WebSocket

作者 Chris Heilmann

Firefox 4 和 Opera 中不支持 WebSocket，直到修复安全问题为止

这对开发者来说意味着什么？

正在修复中

关于 Chris Heilmann

发现 Web 开发的宝贵资源

谢谢！请检查您的收件箱以确认您的订阅。