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

Question

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

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

假设用户访问网站A，该网站提供向网站Z发出Web服务请求的代码。但是我已经入侵并破坏了网站Z，并将其变成了一个攻击站点。我很快让它对所有 CORS 请求做出积极响应( header 添加 Access-Control-Allow-Origin:“*”)。很快用户的计算机就被我从 Z 的攻击破坏了。

在我看来，用户从未直接访问过 Z，对 Z 的存在一无所知，也从未“认可”Z。而且在我看来 - 即使在破解被知晓后 - 网站什么也没有可以做些什么来阻止它(除了自己脱机之外:-)。出于安全考虑，难道不会强制要求 A 证明 Z，而不是 Z 证明 A 吗？我错过了什么？

Answer 1

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

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

(有更好理解的 friend ，请根据需要补充或更正!)