关于跨源资源共享（CORS）如何工作的困惑

根据我对CORS的理解，这就是它的工作原理：我有一个网站foo.com，它提供页面X.X想要将数据发布到另一个域bar.com。 如果bar.com启用了CORS（其标题生成Access-Control-Allow-Origin foo.com），则页面X现在可以将数据发送到bar.com。

据我所知，让CORS工作就是关于在bar.com上设置，而与foo.com无关。 这一切都是为了确保bar.com不接受来自任何旧域的请求。

然而，这对我来说真的没有意义。 我认为CORS旨在使foo.com能够决定允许哪些X与之通信。 如果我们回到前面的例子，但这次X被狡猾的脚本破坏，以便它秘密地向evil.com发送数据，CORS将如何阻止它？ evil.com已启用CORS，并设置为*，因此它将接受来自任何内容的请求。 这样一来，用户认为他们使用网站foo.com，就会无意中将数据发送到evil.com。

如果它真的是关于bar.com保护自己的，那为什么它会使浏览器执行该策略呢？ 唯一可以想象的情况是，如果你让evil.com服务于冒充foo.com的页面Y，那就试图将数据发送到bar.com。 但是CORS是由浏览器强制执行的，你所要做的就是让evil.com成为一个将伪造的原始请求发送到bar.com的代理（数据从Y发送到evil.com，evil.com将其假的来源设置为foo .com然后将其发送到bar.com）。

如果它以相反的方式工作，那对我来说才有意义。 foo.com启用了CORS，其标头设置为Access-Control-Allow-Origin bar.com。 这样，胭脂脚本将被浏览器拒绝访问evil.com。 然后，浏览器强制执行策略是有意义的，因为它运行的脚本可能会变成胭脂。 它不会阻止rouge网站尝试将rouge数据发送到bar.com，但bar.com可以使用用户名/密码保护自己。 如果foo.com的端点是期望从X返回数据，那么您可以将令牌嵌入X中，以确保evil.com不会向其发送数据。

我觉得我在这里不了解一些根本重要的东西。 真的很感激帮助。

Answer 1

然而，这对我来说真的没有意义。 我认为CORS旨在使foo.com能够决定允许哪些X与之通信。

不，这是关于bar.com控制其内容的使用。

但是CORS是由浏览器强制执行的，你所要做的就是让evil.com成为将伪造的原始请求发送到bar.com的代理…

对。 如果您这样做，并且bar.com上的人员会注意并关心他们，他们会拒绝来自您服务器的请求。 你移动它，他们不允许新的。 哇鼹鼠的时间。 但是，就像那种捣蛋游戏一样令人痛苦的是，与来自桌面的foo.com的每个用户直接提出请求相比，它的痛苦要小得多。

让foo.com强制执行foo.com所能做的事情没有任何意义。 foo.com 已经强制执行foo.com可以做的事情，因为它是foo.com，提供foo.com的内容和脚本。

Answer 2

它不是关于Foo.com，也不是关于Bar.com。 这是关于用户。

CORS有两件事可以防范。 首先是访问防火墙后面的资源。 第二种是通常受保护的资源，除非从具有身份validation或其他敏感数据cookie的浏览器发送请求。

CORS是一种浏览器技术，在服务器的支持下，允许foo在其域外进行有限的自由调用。 这是对跨域脚本限制的限制性漏洞。

任何人都可以伪造ORIGIN标头并创建一个CORS预检或简单请求 – 当然，任何人都可以直接连接到Bar服务器并在不使用CORS的情况下发出请求。 任何浏览器都可以直接连接到bar.com并获取数据。 但是现代浏览器不会运行访问bar.com资源的foo.com脚本。 访问网站的人员不会访问旨在利用cookie的网站或浏览器位于公司防火墙后面的事实。

所以接受的答案是错误的。 它不是关于bar.com保护其资源 – 它通过身份validation和授权来实现。 您不必创建代理来发送CORS请求 – 您创建一个代理来去除CORS请求（自动响应预检请求，并将正确的标头返回给浏览器，但向bar发送正常请求）。 COM）。 但是你仍然需要身份validation来获取bar.com的资源，而foo.com仍然需要以某种方式让你安装代理来利用CORS保护的跨域脚本漏洞。

但最后的句子是正确的 – foo.com无法控制资源 – 它是浏览器，快速检查bar.com，询问它是否是预期的。

来自OP：

如果它真的是关于bar.com保护自己的，那为什么它会使浏览器执行该策略呢？ 唯一可以想象的情况是，如果你让evil.com服务于冒充foo.com的页面Y，那就试图将数据发送到bar.com。 但是CORS是由浏览器强制执行的，你所要做的就是让evil.com成为一个将伪造的原始请求发送到bar.com的代理（数据从Y发送到evil.com，evil.com将其假的来源设置为foo .com然后将其发送到bar.com）。

evil.com已经可以联系bar.com了 – 就像任何使用浏览器的人一样（或curl或wget等）。 问题是，evil.com强制您的浏览器连接到bar.com，它可能有IPfilter，cookie，防火墙等保护它，但javascript可以连接到使用您的浏览器。 因此浏览器是保护用户的东西。 禁止跨域脚本。 但有时它是有用的（例如：谷歌apis，或连接到账单支付服务的银行等）跨域脚本。 CORS告诉浏览器在这种情况下它没问题。

这并不是说没有漏洞，或者标准是最好的，或者浏览器中没有漏洞，或者网站过于宽松。 但那些是不同的问题……