【发布时间】: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