跨域是怎么回事？答案

【问题标题】：How is Cross-Domain even a thing?跨域是怎么回事？
【发布时间】：2018-01-21 06:57:05
【问题描述】：

我不明白我想问的某些事情。

场景 1：我创建了一个 HTML/JavaScript 网站，在其中我使用 AJAX 获取 Google.com 的 HTML，我遇到了臭名昭著的跨域问题 (No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.)

场景 2：我输入 www.google.com，我在上下文菜单中选择 Source Code 并获得输入代码。

以下是问题：

此消息（及其含义）有什么用途？当我可以通过浏览器请求同一个网站时，谷歌如何保护我免受我的邪恶脚本的侵害？请求不一样吗？
当来源是浏览器、我的笔记本电脑、我的路由器、我的 ISP、互联网和谷歌时，方案 1 和方案 2 之间的来源差异如何。
为什么以及是谁发明了区分本地脚本和浏览器本身的方法，它的用途是什么？如果请求是恶意的，那么在这两种情况下都同样是恶意的。
Google 如何知道它的来源以及它与我通过地址栏请求他们的网站有何不同？再次，完全相同的来源。

【问题讨论】：

我之前也有同样的问题，但我不记得所有的答案（那个人在我脑海里说），但我记得的一件事是，如果你可以在你的域之外使用 AJAX ，那么您可能会通过向“file:///Users/...”发送请求来访问用户文件。我想我仍然不明白为什么在不阻止访问其他网站的情况下无法阻止这种情况。
我在这上面浪费了 3 天。那些 3 天非常糟糕的地方。我启用了cors和一切。我认为在使用 localhost 时会导致这种情况。
是的，但file:///Users/ 立即表示本人。如果您请求file:///，您绝对不会请求外国网站。您尝试访问自己的文件系统。所以这对我来说仍然没有意义。
Why does my JavaScript get a "No 'Access-Control-Allow-Origin' header is present on the requested resource" error when Postman does not?的可能重复
@J.Doe，如果您让某人在他们自己的系统上打开一个 html 文档并且它可以向您的文件系统发出请求，那么对他们做一些事情或将他们/其中的数据发送到另一个网址。那可能很危险。但同样，我假设浏览器能够区分对文件系统和另一个网站的请求。

标签： javascript ajax web cors

【解决方案1】：

Origin 与您的浏览器、笔记本电脑、路由器、ISP 等无关。Origin 与发出请求的域有关。因此，如果脚本https://evil.com/devious.js 正在向http://google.com 发出XHR 请求，则请求的来源是evil.com。谷歌从来不知道这一点。用户的浏览器检查访问控制标头（您提到的Access-Control-Allow-Origin）并验证该脚本是否被允许发出该请求。

所有这些的目的是防止恶意脚本（用户不知道）代表他们向 Google 发出请求。在银行的背景下考虑这一点。您不希望来自任何其他网站的任何脚本能够向银行发出请求（代表您的从您的浏览器）。银行可以通过禁用跨域请求来防止这种情况发生。

对于 (1)：当您在 google.com 页面上打开控制台时，您发出的任何请求都来自 google.com，这就是您能够发出这些请求的原因。这与我刚刚提到的情况不同，因为用户必须有意识地复制一些恶意 javascript，访问他们银行的网站，打开控制台，然后粘贴并运行它（许多用户会怀疑)。

【讨论】：

我在evil.com 请求期间不是从evil.com/devious.js 下载的脚本，我的浏览器不是向google.com 发出请求吗？这有什么区别？
“在evil.com请求期间”是什么意思？是的，您的浏览器请求https://evil.com/devious.js。但是该脚本发出的任何请求都标记有来源evil.com。因此，如果它尝试请求google.com（例如通过AJAX），浏览器就知道它来自evil.com。浏览器将执行 HEAD 请求并确定是否设置了 CORS（并且此请求由 CORS 标头服从）。
这不是很容易被欺骗吗？我的浏览器只是说谎它不是来自域吗？它不会使整个操作变得无用吗？
没关系，我明白了。这是为了防止本地脚本在没有我意愿的情况下进行交互。现在我懂了。这是我的保护，而不是他们的保护，他们通过阻止这些请求来提供帮助。
是的，但攻击者无法控制浏览器。浏览器试图保护用户。当然，是的，如果浏览器被入侵或恶意 CORS 将毫无用处。但假设不是，浏览器想要保护用户，因此它会拒绝违反 CORS 的请求。

【解决方案2】：

网站通常不是无状态的，它们通常会在您的计算机上存储信息，例如识别您登录帐户的会话 cookie。如果您的浏览器没有阻止未明确允许的跨源请求，您可以登录到 gMail，然后访问 randomguysblog.org，randomguysblog.org 上的脚本可以使用您的浏览器向 gMail 发出 POST 请求。由于您已登录，他可以代表您发送电子邮件。也许您还登录了您的银行，而 randomguy 决定将您的所有资金转入他的帐户，或者只是环顾四周，看看您有多少钱。

单独回答您的问题：

此消息（及其含义）有什么目的？当我可以通过浏览器请求同一个网站时，谷歌如何保护我免受我的邪恶脚本的侵害？请求不一样吗？

受保护的不是 Google，而是您网站的用户也登录了 Google。请求是相同的，但是假设服务器支持预飞行，用户浏览器甚至不会发送请求，如果服务器不支持预飞行请求，那么它将发送请求但不允许脚本启动它以查看响应。还有其他不使用 Ajax 的方式来发送请求而不会看到响应，例如通过提交隐藏表单，这就是为什么还需要 CSRF 令牌的原因。一个 CSRF 令牌使一个操作需要两个请求，并且需要第一个请求的响应中的一个令牌来发出第二个请求。

当来源是浏览器、我的笔记本电脑、我的路由器、我的 ISP、互联网和谷歌时，场景 1 和场景 2 之间的来源差异在这两种情况下有何不同。

在场景 2 中，用户自己提出了两个请求，因此他们必须打算同时提出两个请求。在场景 1 中，用户只是尝试访问您的网站，而您的网站正在使用他们的浏览器向 Google 发出请求，而他们可能不希望您的网站这样做。

为什么以及是谁发明了针对浏览器本身区分本地脚本的方法，它的目的是什么？如果请求是恶意的，那么在这两种情况下都同样是恶意的。

目的是保护浏览器用户免受恶意脚本的侵害。在场景 1 中，恶意脚本无法访问来自 Google 的响应。用户可以，但并非旨在保护用户免受攻击。

Google 如何知道它的来源，这与我通过地址栏请求他们的网站有何不同？再次，完全相同的起源。

Google 可以检查referrer 标头，但他们实际上不需要知道请求的来源。 Google 只需要告诉浏览器允许请求来自哪里，用户的浏览器决定是否将请求发送给 Google。

【讨论】：