【问题标题】:cross-origin xhr and same-origin-policy跨域 xhr 和同源策略
【发布时间】:2014-02-01 18:50:09
【问题描述】:

这是一个我以为我理解的概念,但最近发现我错了。我浏览了整个互联网,找到了很多小细节和代码 sn-ps 的示例,但我仍然不了解它阻止了什么以及为什么阻止它以及为了谁而阻止它。因此,这更像是对高级解释的要求,而不是一个问题。

无论如何,这就是我认为我理解的内容:

假设我有域 A.com 和域 B.com。每个都在他们自己的 apache 服务器上,拥有自己的 IP 地址。 我将域 A.com 中的 html 文件加载到浏览器中。浏览器向 B.com/doStuff.php 执行 POST XMLHttpRequest,但由于设置了相同域策略而失败。

所以: 谁的同域策略是相关的?我认为答案是 B.com/doStuff.php 的……对吗?因此,当 A 发送请求时,B 检查请求标头的来源并说“哎呀,不同的域,不会听你的”。还是 A 发送请求,B 使用指定“same-domain-policy”的标头进行响应,然后浏览器检查是否因为指定了 same-domain-policy,并且 A 请求标头中的域不匹配来自 B 的请求浏览器拒绝发送 xhr?

如果是这样的话,似乎不允许跨域请求是因为“我不希望除我之外的任何人访问我的 API”。这就是全部?因为您不想通过某种身份验证来解决这个问题吗?难道就不能用伪造的源头构造一个 HTTP 请求吗(简直是谎言)?

或者这是否应该以某种方式保护用户?如果是这样,阻止他们调用您的 API 将如何保护任何人?

我很困惑......

【问题讨论】:

  • 它不会阻止机器使用例如 curl 来获取 url,它只会尝试停止基于浏览器的获取。要阻止非 js 威胁,您必须​​进行身份验证。关键是,未经您明确允许,未签名的 JS 无法重新嵌入网站的内容。
  • @dandavis 不是那么容易回避吗?只需让您的服务器获取它的 javascript 请求(例如使用 curl),然后将其传递回 javascript...有什么意义?
  • 重点是控制和责任:服务器/php 代码注册到信用卡,普通旧网页没有。在您的示例中,可以轻松识别和阻止执行 curl 的服务器,但如果流量来自注入广告的 javascript,则请求可能来自任何地方...
  • @dandavis - 但是如果我们依赖现代浏览器在它们发送的原始标头中兼容,那么无论如何都可以轻松找到恶意 javascript 的来源(它将在 HTTP 请求的标头中发送),不是​​吗?
  • 对于受感染的广告,js 会从潜在的数千个其他域加载您域上的内容。 SOP 应该保护受版权保护的材料不被无形地混搭并在没有广告的情况下呈现。这不是世界上最全面的政策,您仍然可以在任何地方提交表单,从任何地方加载图像和脚本,使用 jsonp 等。它实际上更像是早期网络的一个神器,被每个网络专业人士视为给予。 CORS 在选择加入的基础上放宽了它,而不是完全取消限制。它可以防止成群结队的僵尸,就是这样......

标签: javascript php xmlhttprequest same-origin-policy cross-domain-policy


【解决方案1】:
Who's same-domain-policy is relevant?

接收请求的服务器决定。

... the BROWSER refuses to send out the xhr?

不,服务器拒绝响应。更准确地说,在现代浏览器中,它是由preflighted requests 完成的。这意味着对于每个跨域请求,首先由浏览器自动发送一个 OPTIONS 请求,其标头与预期请求将具有的完全相同,但没有请求正文。服务器也仅使用标头进行响应。响应中的访问控制标头将让客户端浏览器知道请求是否会根据服务器的策略得到满足。从某种意义上说,浏览器正在阻止该请求,但这仅仅是因为它已经与服务器交换了一个请求/响应对,并且知道尝试该请求是没有意义的。如果你在这种情况下伪造请求,服务器仍然会拒绝提供它。

【讨论】:

  • 好的,这是有道理的。谢谢你澄清!但是-然后我是否纠正了整个事情的唯一目的是禁止人们访问您的 API,但只能通过 javascript 访问? (IE-您的 API 仍然可以被其他任何东西访问,javascript 不能这样做的唯一原因是因为浏览器不支持 JS 编辑它的原始标头的方法?)。那是在保护谁?您的 API 仍然可以访问 - 它只需要一个简单的解决方法(告诉您的服务器进行调用,然后将其传递回您的 js)。
  • “只需要一个简单的解决方法”是一个不那么小的“公正”,仅此区别就构成了基本客户端网络安全的基石。 php 服务器可以关闭,rouge 脚本更难消除,并且比 curl 或 php 任何人及其兄弟都可以编写的问题要大得多。
  • @dandavis - 基本客户端网络安全的基石?!如果存在我(一个被承认的新手)可以轻松利用的解决方法(再次,可能不是这种情况 - 我仍在等待/希望得到纠正......),客户端网络搞砸了!充其量这似乎只是懒惰黑客的前线障碍......?如果就是这样,那就这样吧。但我觉得我一直在听到喋喋不休的声音,好像这种事情很重要。 (我真的没有不尊重的意思-我只是仍在努力掌握这一切,并且确信我仍然缺少某些东西......)
【解决方案2】:

这个想法是您不想通过 Javascript 从服务器 A 访问服务器 b。如果您正在与 API 交互,您将使用 javascript 调用您自己服务器的后端代码,然后该代码将调用另一台服务器。

【讨论】:

  • 但是为什么呢? “我不希望有人从 javascript 访问我的 API,但如果他们从 PHP 访问它就可以了”似乎是一个完全肤浅的理由来证明这个基础设施......
猜你喜欢
  • 2013-01-18
  • 2014-06-05
  • 2013-04-12
  • 2017-01-05
  • 2011-02-20
  • 2014-10-13
  • 2011-12-26
  • 2011-10-24
相关资源
最近更新 更多