开发者不理解CORS 2019年7月10日 — 克里斯·福斯特 在全栈咨询工作中最好的事情之一就是我能与来自各个规模和行业的不同技能水平的开发者合作。这提供了一个机会，让我看到各种普遍的难题。其中一个最近显得特别相关的问题是：太多的Web开发者不知道CORS是如何工作的。这一点尤其重要，因为最近发现了Zoom的一个漏洞。安全研究员乔纳森·莱奇胡发现Zoom在机器上有一个在http://localhost:19421上侦听的Web服务器。当你加载Zoom链接时，Zoom的网站会向本地主机Web服务器发送请求，并告诉它打开本地Zoom应用程序。整篇文章值得一读，但这些部分让我印象深刻：我还发现，这个页面不是发起常规的AJAX请求，而是从本地运行的Zoom Web服务器加载一张图像。图像的不同尺寸决定了服务器的错误/状态代码。你可以在这里看到案例切换逻辑。我问的一个问题是，为什么这个Web服务器返回的数据会以图像文件的尺寸进行编码？原因是，这样做是为了绕过跨域资源共享（CORS）。出于非常明确的原因，浏览器明确忽略在localhost上运行的服务器的任何CORS政策。最后一句话是错误的——Chrome确实尊重本地Web服务器的CORS头。如果你是一名Web开发者，你可能已经做过这样的操作，当你有一个创建React应用程序时，前端应用程序在一个端口，后端API在另一个端口。你的应用程序正在向localhost发起跨域请求，并且这一点在所有浏览器中都受支持。这让我想到Zoom可能需要推出这个功能而不了解CORS。他们无法进行AJAX请求，因为浏览器阻止了这个尝试。相反，他们构建了这个图像黑客来绕过CORS。这样做，他们让Zoom暴露于一个很大的漏洞，因为不仅Zoom网站可以触发本机客户端的操作并访问响应，而且互联网上的任何其他网站也都可以。因此，这个功能的安全实现应该是什么样的呢？在localhost:19421上侦听的Web服务器应该实现一个REST API，并设置一个带有https://zoom.us值的Access-Control-Allow-Origin头。这将确保只有在zoom.us域上运行的JavaScript可以与本地主机Web服务器通信。此外，为了防止页面能够在后台自动打开Zoom会议，zoom.us应该具有一个Content Security Policy头，阻止在iframe中渲染。这仍然留下了一个漏洞，即任何页面都可以将你的浏览器重定向到一个你不期望的zoom.us会议链接，但这是Zoom所做的用户体验决策，而不是软件漏洞。就我个人而言，我认为这种方法也是错误的。他们提到希望通过直接打开应用程序来改善用户体验，但良好的用户体验设计的一条规则是，软件必须是可预测的。如果我点击一个链接，我期望它不会突然让我的摄像头和麦克风对我不认识的人开放。Zoom正在打破这种期望。即使他们出于用户体验的原因不想要内置的浏览器弹出窗口，也要把这个弹出窗口放在应用程序内！Google Meet做得很好：我不想偏离这篇文章对CORS的关注。无论用户体验的争论如何，在localhost上运行Web服务器本身就是一项高风险的工作。它绝对不应该向互联网上的每个网站提供特权访问功能，例如安装软件。CORS使你能够安全地做到这一点——不要绕过它！我并不能确定不理解CORS是否是Zoom以这种方式实现这个功能的原因。然而，我曾与几个人交谈，我们没有人能集体找到任何合理的理由来实施他们现有的方法。在reddit上，lerunicorn确实找到并建议Firefox可能会阻止从安全源到不安全源的XHR，这可能解释了这种方法背后的动机。然而，当源是localhost时，Firefox支持这一点。此外，本地应用程序可以生成一个唯一的自签名证书。或者，他们可以使用浏览器扩展。在任何情况下，这都不是忘记过滤源的有效理由。不只是Zoom。我与许多开发者交流过，非正式地，他们都不太了解CORS的工作原理。Stack Overflow上出现了大量的示例。不幸的是，这些例子通常与推荐非常不安全的默认设置的页面配对，比如express中的这个，如果逐字复制，会使你的应用程序面临风险。其他供应商也被发现有和Zoom相同的漏洞。开发者只是想让他们的代码工作，而绕过...