为什么浏览器API限制跨网域请求？ [英] Why do browser APIs restrict cross-domain requests?

问题描述

XMLHttpRequest 需要CORS才能工作于跨网域。类似地，对于Web字体，WebGL纹理和一些其他的东西。一般来说，所有新API似乎都有此限制。

XMLHttpRequests require CORS to work cross-domain. Similarly for web fonts, WebGL textures, and a few other things. In general all new APIs seem to have this restriction.

为什么？

它需要一个简单的服务器端代理。换句话说，不禁止服务器端代码执行跨域请求;为什么是客户端代码？

It's so easy to circumvent: all it takes is a simple server-side proxy. In other words, server-side code isn't prohibited from doing cross-domain requests; why is client-side code? How does this give any security, to anyone?

这是不一致的：我不能 XMLHttpRequest ，但是我可以< script src> 或< link rel> 或< img src> ; 或< iframe> 。

And it's so inconsistent: I can't XMLHttpRequest, but I can <script src> or <link rel> or <img src> or <iframe>. What does restricting XHR etc. even accomplish?

推荐答案

如果我访问恶意网站，我想确定：

If I visit a malicious website, I want to be sure that :

1. 无法从我使用的其他网站读取我的个人资料。 Think attacker.com阅读gmail.com


2. 无法在我使用的其他网站上代表我们执行操作。认为attacker.com通过bank.com上的帐户转移资金。

1. It cannot read my personal data from other websites I use. Think attacker.com reading gmail.com
2. It cannot perform actions on my behalf on other websites that I use. Think attacker.com transferring funds from my account on bank.com

同源政策解决了第一个问题。第二个问题称为跨站点请求伪造，并且无法通过当前存在的跨域限制解决。

Same Origin Policy solves the first problem. The second problem is called cross site request forgery, and cannot be solved with the cross-domain restrictions currently in place.

同源策略一般与以下内容一致规则 -

The same origin policy is in general consistent with the following rules -

• 规则1：不允许您从其他网域阅读任何内容


• 规则


• 规则3：您可以自由地创建跨网域GET请求和POST请求，但您无法控制HTTP标头

让我们看看您所列出的各种内容符合上述规则： / p>

Lets see how the various things you have listed line up to the above rules :

1. < img> 标记可让您发出HTTP请求，除了简单地显示图像之外，没有办法读取图像的内容。例如，如果我这样做< img src =http://bank.com/get/latest/funds/> ，请求将通过（规则2）。但是攻击者无法看到我的平衡（规则1）。

1. <img> tags let you make a HTTP request, but there is no way to read the contents of the image other than simply displaying it. For example, if I do this <img src="http://bank.com/get/latest/funds"/>, the request will go through (rule 2). But there is no way for the attacker to see my balance (rule 1).

< script> 标签的工作方式主要类似于< img> 。如果您执行< script src =http://bank.com/get/latest/funds> ，请求将通过。浏览器还会尝试将响应解析为JavaScript，并且会失败。

<script> tags work mostly like <img>. If you do something like <script src="http://bank.com/get/latest/funds">, the request will go through. The browser will also try to parse the response as JavaScript, and will fail.

有一个众所周知的滥用< script> ; 标签称为JSONP，您可以与跨域服务器合并，以便可以读取跨域。但是如果没有跨域服务器的明确参与，您将无法通过< script> 标记

There is a well known abuse of <script> tags called JSONP, where you collude with the cross-domain server so that you can 'read' cross-domain. But without the explicit involvement of the cross-domain server, you cannot read the response via the <script> tag

< link> 用于样式表的工作方式大多与< script> 评价为CSS。一般来说，你不能读取响应 - 除非响应以某种方式恰好是良好的CSS。

<link> for stylesheets work mostly like <script> tags, except the response is evaluated as CSS. In general, you cannot read the response - unless the response somehow happens to be well-formed CSS.

< iframe> 本质上是一个新的浏览器窗口。您无法读取跨网域iframe的HTML。顺便提及，您可以更改跨网域iframe的网址，但无法读取网址。注意它是如何遵循我上面提到的两个规则。

<iframe> is essentially a new browser window. You cannot read the HTML of a cross-domain iframe. Incidentally, you can change the URL of a cross-domain iframe, but you cannot read the URL. Notice how it follows the two rules I mentioned above.

XMLHttpRequest 是进行HTTP请求的最通用的方法。这完全是在开发者控制;浏览器不响应响应。例如，在< img> ，< script> 或< ; link> ，浏览器假定为特定格式，一般会适当地进行验证。但在XHR中，没有规定的响应格式。

XMLHttpRequest is the most versatile method to make HTTP requests. This is completely in the developers control; the browser does not do anything with the response. For example, in the case of <img>, <script> or <link>, the browser assumes a particular format and in general will validate it appropriately. But in XHR, there is no prescribed response format. So, browsers enforce the same origin policy and prevent you from reading the response unless the cross domain website explicitly allows you.

通过字体，您的浏览器会强制执行相同的原始政策并阻止您阅读回复。 font-face 是一个异常。 AFAIK，只有Firefox需要选择加入行为;其他浏览器让你像使用图像一样使用字体。

Fonts via font-face are an anomaly. AFAIK, only Firefox requires the opt-in behavior; other browsers let you use fonts just like you would use images.

简而言之，同一来源政策是一致的。如果您发现跨网域请求和在没有得到跨网站网站的明确许可的情况下阅读响应，您将在全球范围内成为头条新闻。

In short, the same origin policy is consistent. If you find a way to make a cross-domain request and read the response without explicit permission from the cross-domain website - you'll make headlines all over the world.

EDIT ：为什么我不能使用服务器端代理解决所有这些问题？

EDIT : Why can't I just get around all of this with a server-side proxy?

对于gmail显示个性化数据，它需要您的浏览器的Cookie。有些网站使用HTTP基本身份验证，其中凭据存储在浏览器中。

For gmail to show personalized data, it needs cookies from your browser. Some sites use HTTP basic authentication, in which the credentials are stored in the browser.

服务器端代理无法访问Cookie或基本认证凭据。因此，即使它可以发出请求，服务器也不会返回用户特定的数据。

A server-side proxy cannot get access to either the cookies or the basic auth credentials. And so, even though it can make a request, the server will not return user specific data.

这篇关于为什么浏览器API限制跨网域请求？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！