同源政策的可疑目的

Posted 2023-02-19

【中文标题】同源政策的可疑目的

【英文标题】：Dubious purpose of the same origin policy

【发布时间】：2015-03-01 22:02:34

【问题描述】：

正如我所读到的，同源策略是关于防止来自（邪恶）域 A 的脚本向（好）域 B 发出请求 - 换句话说，跨站点请求伪造。

玩了一下，我了解了Access-Control-Allow-Origin 标头和CORS，据我所知，它们允许从良好的域 B 中指定服务器，即域 A 是允许的来源（因此不是邪恶的）。如果跨域响应中不存在此标头，则浏览器将不会从中读取任何内容，但它已经发出了请求。

现在，我不知何故错过了这里的重点。如果域 B 有 Web 服务 API 和用户登录的 cookie 身份验证，基本上任何操作都可以由邪恶的来源 A 代表可怜的用户执行，只是攻击者看不到响应。

我在这里缺少什么？我的推理哪里出错了？

【问题讨论】：

developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS - 从预检请求开始读取并继续读取带有凭据的请求。

整个域不必启用 CORS，只需启用他们想要并准备保护的接入点。毫无戒心的域被置之不理

@Bjorn 从该链接我了解到，一些带有凭据的 POST 请求将在没有经过预检的情况下完成，因此仍然可以完成具有影响的 API 调用。

【参考方案1】：

CORS 不会阻止在 CORS 发明之前允许的任何事情。它只为网站指定了一种允许以前总是被拒绝的请求的方式。

自 Web 诞生以来，一个站点总是会导致用户代理向其他站点发出请求。想想热链接的图片吧。

通常，站点仅基于 cookie 授权操作是不正确的，因为正如您所指出的，任何站点都可以使用其他站点的 cookie 发出请求。

网站通常会要求请求包含 cookie 以外的内容。例如，它可能会查找必须从先前响应中读取的 CSRF 令牌。作为站点 B，您需要使用 CORS 来获取此令牌。

【参考方案2】：

正如我所读到的，同源策略是关于防止来自（邪恶）域 A 的脚本向（好）域 B 发出请求 - 换句话说，跨站点请求伪造。

同源策略可防止从另一个源读取不匹配的域、端口或协议组合。它没有提到限制请求一开始就提出。

例如

http://www.example.com 无法读取 http://www.example.edu 上的任何内容 https://www.example.com 无法读取 http://www.example.com 上的任何内容（cookie 除外，因为 cookie 的同源策略不同） http://www.example.com:8080 无法读取 http://www.example.com 上的任何内容

同源策略不会阻止向另一个域提出请求。只有响应是只读的。所以...

http://www.example.com 可以通过 AJAX 或表单将数据 POST 到 http://www.example.edu（如果在浏览器中启用了 3rd 方 cookie，即使使用凭据） http://www.example.com 可以通过 AJAX 或表单 POST 数据到 https://www.example.com 就同源策略而言，https://www.example.com 可以将数据发布到http://www.example.com，尽管浏览器很可能会阻止请求或在通过 HTTPS 页面访问 HTTP 内容时警告用户。当然，当通过 AJAX 时，通过表单将取决于浏览器和设置 http://www.example.com 可以从 http://www.example.edu 加载图像，但是图像数据将无法通过脚本获得

因此 CORS 不会放松已经可能实现的安全性，它允许域选择加入 CORS 并允许另一个域从中读取响应。