出于安全考虑，千万不要绕开 CORS！

Mac Zoom 漏洞的曝出将 CORS（跨源资源分享，Cross Origin Resource Sharing）拉入了大众视野，但是坦白地讲，“不了解 CORS 的 Web 开发人员实在太多了”——无论是新手还是经验丰富的开发人员。那么是因为 CORS API 过于复杂和混乱？还是说开发者需要围绕 CORS 和 CSP 等问题对开发人员展开更好的教育？......无论是何种情况，这都不...

CSDN资讯

3446人浏览 · 2019-08-06 15:32:12

CSDN资讯 · 2019-08-06 15:32:12 发布

640?wx_fmt=gif

Mac Zoom 漏洞的曝出将 CORS（跨源资源分享，Cross Origin Resource Sharing）拉入了大众视野，但是坦白地讲，“不了解 CORS 的 Web 开发人员实在太多了”——无论是新手还是经验丰富的开发人员。

那么是因为 CORS API 过于复杂和混乱？还是说开发者需要围绕 CORS 和 CSP 等问题对开发人员展开更好的教育？......无论是何种情况，这都不是忘记过滤数据源的正当理由。

声明：本文已获作者 Chris Foster 翻译授权。

640?wx_fmt=jpeg

作者 | Chris Foster

译者 | 弯月，责编 | 郭芮

出品 | CSDN（ID：CSDNnews）

以下为译文：

从事全栈技术咨询工作的最大优势就在于，我可以与大量来自各个行业、不同规模、不同技术水平的开发人员合作。这是一个了解“民间疾苦”的良机。最近我发现了一个普遍的问题：不了解CORS（Cross Origin Resource Sharing，跨源资源分享）工作原理的Web开发人员实在太多了。

鉴于最近的Zoom漏洞，我觉得应该及时指出这个问题。安全研究员Jonathan Leitschuh发现Zoom会在本地启动一个Web服务器监听http://localhost:19421。当你加载Zoom的链接时，Zoom网站会向localhost的Web服务器发送请求，并指示它打开本地的Zoom应用。

Jonathan Leitschuh介绍表示（在CSDN此前发布的《Mac 被曝存在恶意漏洞：黑客可随意调动摄像头，波及四百万用户！》一文中也曾详细报道过）：

我还发现，该页面发出的不是常规的AJAX请求，而是从在本地运行的Zoom Web服务器中加载图像，图像的尺寸代表不同的服务器错误/状态代码。

其中的case-switch逻辑如下：

让我感到费解的一个问题是，为什么这个Web服务器会返回通过图像文件的尺寸编码的数据？原因在于，这样做可以绕过跨源资源分享（Cross Origin Resource Sharing，即CORS）。实际上浏览器会有意忽略localhost上运行的服务器的所有CORS策略。

——上述最后一句话不正确，因为Chrome确实会遵循localhost Web服务器的CORS头。

如果你是一名Web开发人员，那么当你使用前端应用创建的React应用在某个端口上，而你的后台API在另一个端口上时，你很可能也遇到过这种情况。你的应用会对localhost发出跨源请求，而且所有浏览器都支持该功能。

在我看来，Zoom在发布这个功能的时候并不理解CORS。如果浏览器禁止这种操作，那么他们也就无法发送这样的AJAX请求。相反，他们利用图像绕开了CORS问题。然而，他们的这种做法实际上在Zoom中埋下了一个重大漏洞，因为不仅Zoom网站可以触发本机客户端的操作并访问响应，互联网上的任何其他网站也可以。

那么怎样才能安全地实现这个功能呢？监听localhost:19421的Web服务器应该实现REST API，并将Access-Control-Allow-Origin头设置为https://zoom.us。这样就可以确保只有在zoom.us域上运行的JavaScript才能与localhost的Web服务器通信。此外，为了制止页面自动在后台打开zoom.us，还应该设置一个能够阻止iframe渲染的内容安全策略（Content Security Policy，即CSP）头。

即便如此，仍然还有一个漏洞：任何页面都可以将浏览器重定向到zoom.us链接，让你意外闯入一个陌生的会议。但这是Zoom设计的用户体验，并非软件漏洞问题。就个人而言，我认为这种方法也不正确。他们曾提到他们希望通过直接打开应用程序来增强用户体验，但良好的用户体验设计规则之一就是软件的行为应该在用户的预料之中。

我可不希望在点击一个链接的时候，突然与不认识的人视频。Zoom打破了用户的这种期望，即使出于用户体验的原因，他们不希望浏览器显示内置的弹出窗口，他们也应该在应用中显示此弹出窗口！Google Meet就是这么做的：

640?wx_fmt=png

让我们重回CORS的话题。姑且不论用户体验如何，在localhost上运行Web服务器都存在风险。绝对不应该为互联网上的每个网站提供访问某些功能的特权，例如安装软件。CORS可以确保这种安全性，所以千万不要绕开CORS！

我不清楚Zoom采用这种方式实现该功能的原因究竟是不是他们没理解CORS。但是，我与多个人进行了交谈，我们都认为除此之外没有其他合理的理由来解释他们的这种实现。在Reddit上，lerunicorn有了新的发现，他说Firefox可以阻止从安全的位置引用非安全数据源的XHR，这可以解释Zoom采用这种实现背后的动机。但是，即使数据源是localhost，Firefox也支持该功能。或者，还可以让本地应用生成唯一的自签名证书。再不济还可以使用浏览器扩展。无论是何种情况，这都不是忘记过滤数据源的正当理由。

不仅仅是Zoom，很多与我有过交谈的开发人员也都不了解CORS的工作原理。Stack Overflow上就有很多这类的例子。不幸的是，很多问题的答案推荐的都是非常不安全的默认设置，比如这一段ExpressJS的代码（https://enable-cors.org/server_expressjs.html），如果你完全复制的话，你的应用程序就很容易受到攻击。其他软件开发商也有与Zoom相同的漏洞。

开发人员只是想让他们的代码运行起来，而绕过同源策略代码恰巧能让程序运行，因此才出现了Zoom如今的局面。

无论是新手还是经验丰富的开发人员，都可能不太理解CORS。是不是因为CORS API过于复杂和混乱？还是说我们需要围绕CORS和CSP等问题对开发人员展开更好的教育？我不确定，但从目前的形式来看，我们还需要加倍努力。

原文：https://fosterelli.co/developers-dont-understand-cors

作者：Chris Foster，软件工程师@Two Story Robot。