CORS 如何为用户提供至少一些安全性？

Posted 2023-03-03

【中文标题】CORS 如何为用户提供至少一些安全性？

【英文标题】：How does CORS provide at least some security to users?

【发布时间】：2013-03-21 12:32:45

【问题描述】：

首先道歉：这对我来说就像一个“愚蠢”的问题，我希望我很快就会后悔问这个问题......但我现在无法弄清楚，因为我的思绪似乎陷入了困境错误的车辙。所以请耐心等待并帮助我：

我的理解是，“同源”是 Web 服务的一个痛点，作为回应，CORS 放宽了限制，足以使 Web 服务合理工作，但仍为用户提供良好的安全性。我的问题是 CORS 究竟是如何做到这一点的？

假设用户访问网站A，该网站提供了向网站Z发出Web服务请求的代码。但是我已经侵入并破坏了网站Z，并将其变成了攻击站点。我很快让它积极响应所有 CORS 请求（标题添加 Access-Control-Allow-Origin：“*”）。很快用户的电脑就被我来自Z的攻击颠覆了。

在我看来，用户从未直接访问过 Z，对 Z 的存在一无所知，也从未“批准”过 Z。而且在我看来——即使在入侵被知晓之后——什么都没有网站可以做些什么来阻止它（本身不能离线:-)。安全问题会不会要求 A 证明 Z，而不是 Z 证明 A？我错过了什么？

【问题讨论】：

通过选择首先向其发出 Web 服务请求而得到有效认证的 Z。

html5rocks.com/en/tutorials/cors developers.google.com/accounts/docs/OAuth2 在你睡不着的时候读4....

就像孩子们说的那样，这就是“lolorama”。

看来来自被颠覆网站的正确 CORS 标头确实有效地完全取消了浏览器的“同源”策略，对吧？那么，为什么还要让浏览器实现 CORS，而不仅仅是让它们放松“同源”政策呢？使用 OAuth 是否有效地承认 CORS 提供的用户安全性严重不足？如果网站 A 通过提供使用 Z 的 javascript 代码来“认证”网站 Z（在其颠覆之前），那么从用户的角度来看，CORS 是否真的完全不相关？ CORS 对其他人的意义真的和我一样吗？

我担心我们在谈论苹果和橘子。一个常见的问题 - 但不是我的 - 是提供服务的站点的安全性（在这种情况下为 Z） - 没有收费错误，没有拒绝更改，没有未经授权的访问等。我更关心的是安全性浏览器用户。从用户的角度来看，问题在于 Z（一个他从未真正访问过、从未收到过帐单、甚至可能不知道存在的网站）在他的计算机上放置了恶意软件。

【参考方案1】：

CORS 对安全没有任何作用。它确实允许销售网络字体的人决定哪些网站可以轻松访问他们的字体。这几乎是唯一的用例。

用户与引入 CORS 之前一样不知道。请记住，跨源请求过去在 CORS 之前就可以工作（人们经常抱怨您必须 shim jQuery 才能在 IE 中获得 CORS 支持......但在 IE 中，您可以直接发出请求并获得响应，而无需任何额外的努力......它刚刚工作）。

一般来说，信任模型是倒退的。正如其他人所说，您通过引用其他网站暗示了信任......所以给我这些可怕的数据！

【参考方案2】：

我也在调查这个问题，因为我的思维过程与你的相似。根据我的新理解：CORS 不提供安全性，它绕过它来提供功能。浏览器一般不允许跨域请求；如果您访问 shady.com，并且那里有一个脚本试图访问 bank.com使用您机器上的 cookie，那么 shady.com 的脚本将能够在 bank.com 上执行操作使用该 cookie 冒充您。为了防止这种情况，bank.com 不会将其 API 标记为启用 CORS，因此当 shady.com 的脚本开始 HTTP 请求时，浏览器本身会阻止该请求。

所以同源保护用户免受他们自己的影响，因为他们不知道什么 auth cookie 存在； CORS 允许代表用户拥有资源的服务器将 API 标记为可从其他站点的脚本访问，这将导致浏览器随后忽略其自己的跨域保护策略。

（有更好理解的，请根据需要补充或更正！）

【讨论】：

关于： _ 为了防止这种情况，bank.com 不会将其 API 标记为启用 CORS，因此当 shady.com 的脚本开始 HTTP 请求时，浏览器本身会阻止该请求。_ .. ：浏览器如何在知道远程服务器是否允许跨源请求之前阻止请求？

@KorayTugay 浏览器实际上会在尝试访问所述 API 之前执行初始请求以确定这一点 - 请参阅 developer.mozilla.org/en-US/docs/Glossary/Preflight_request

imo，重要的是要提到预检请求仅针对特定方法完成，特别是它们不是针对 GET 和 POST 进行的，这些方法 shaddy.com 可能无论如何都会尝试..

我不知道！我查了一下，听起来它可能会发送 POST 的预检等，具体取决于内容类型：***.com/questions/39725955/…

【参考方案3】：

CORS 保护接收请求的网站（在您的示例中为 Z）免受发出请求的网站（在您的示例中为 A）的影响，方法是告知用户的浏览器允许或不允许查看请求的响应。

当 JavaScript 应用程序要求浏览器向与其自己不同的源发出 HTTP 请求时，浏览器不知道这两个源之间是否存在相互协议以进行此类调用。当然，如果请求来自源 A，则 A 同意（如果 Z 是恶意的，A 应对其用户负责），但接收方 Z 是否同意？浏览器知道的唯一方法是询问 Z，它通过实际执行请求来做到这一点。除非 Z 明确允许 A 接收响应，否则浏览器不会让 A 的应用程序读取它。

你说得对，CORS 的唯一作用是放宽同源政策。在此之前，允许跨域请求，浏览器会自动包含它对目的地的 cookie，也就是说，它会向 Z 发送一个经过身份验证的请求。这意味着，在没有同源策略的情况下，A 可以像用户一样浏览 Z，查看它的数据等。同源修复了这个非常严重的安全漏洞，但是因为某些服务仍然需要使用跨域请求有时，会创建 CORS。

请注意，CORS 不会阻止请求被发送，因此如果 A 的 JS 应用程序向 Z 发送请求，命令它将所有用户的钱发送到某个帐户，Z 将收到此请求里面的所有饼干。这称为跨站点请求伪造 (CSRF)。有趣的是，针对此类攻击的主要防御是基于 CORS。它包括在请求中要求一些秘密值（“CSRF 令牌”），该值只能通过跨域请求获得，如果它不在 Z 的授权列表中，则 A 无法获得。如今，同站点 cookie 可以也可以使用，它们更易于管理，但不能跨域工作。