同源策略和CORS（跨域资源共享） [英] Same origin Policy and CORS (Cross-origin resource sharing)

问题描述

我是想了解CORS。按我的理解，这是一个安全在浏览器中实现的机制，以避免任何Ajax请求的域一个用户（在URL中指定）

I was trying to understand CORS. As per my understanding it is a security mechanism implemented in browsers to avoid any ajax request to domain other than the one open by the user (specified in the url)

现在，由于这种限制，许多CORS实施，使网站做跨起源请求。但按我的理解，实施CORS以身试法同源策略 SOP

Now, due to this limitation many CORS was implemented to enable websites to do cross origin request. but as per my understanding implementing CORS defy the security purpose of the "Same Origin Policy" SOP

CORS仅仅是提供额外的控制，这要求服务器需要服务。也许这样可避免垃圾邮件发送者。

CORS is just to provide extra control over which request server wants to serve. Maybe it can avoid spammers.

从维基百科：

要发起一个跨域请求，浏览器发送该请求   原点HTTP标头。标题的值是网站   供应的页面。例如，假设在一个页    http://www.example-social-network.com 的尝试访问用户的数据   在online-personal-calendar.com。如果用户的浏览器工具   CORS，下面的请求头将被发送：

To initiate a cross-origin request, a browser sends the request with an Origin HTTP header. The value of this header is the site that served the page. For example, suppose a page on http://www.example-social-network.com attempts to access a user's data in online-personal-calendar.com. If the user's browser implements CORS, the following request header would be sent:

产地： http://www.example-social-network.com

如果online-personal-calendar.com允许请求时，它发送一个   在答复访问控制 - 允许 - 产地标头。的价值   头指示允许哪些原始站点。例如，一个   应对previous请求将包含以下内容：

If online-personal-calendar.com allows the request, it sends an Access-Control-Allow-Origin header in its response. The value of the header indicates what origin sites are allowed. For example, a response to the previous request would contain the following:

访问控制 - 允许 - 产地： http://www.example-social-network.com

Access-Control-Allow-Origin: http://www.example-social-network.com

如果服务器不允许跨原点请求，浏览器   将提供一个错误example-social-network.com页面，而不是   该online-personal-calendar.com响应。

If the server does not allow the cross-origin request, the browser will deliver an error to example-social-network.com page instead of the online-personal-calendar.com response.

要允许访问的所有页面，服务器可以发送以下响应   标题：

To allow access to all pages, a server can send the following response header:

访问控制 - 允许 - 产地：*

Access-Control-Allow-Origin: *

然而，这可能不适合情况，其中   安全性是一个问题。

However, this might not be appropriate for situations in which security is a concern.

我在想什么吗？ CORS的什么的打算，以确保服务器VS保护客户端。

What am i missing here? what is the the intend of CORS to secure the server vs secure the client.

推荐答案

这是什么？

在同源策略是不同浏览器的标准化的安全措施。在原产地的大多指的域的。它prevents不同来源的相互交融，以prevent攻击，如跨站请求伪造的。

The same-origin policy is a security measure standardized among browsers. The "origin" mostly refers to a "domain". It prevents different origins from interacting with each other, to prevent attacks such as Cross Site Request Forgery.

如何CSRF攻击的工作？

浏览器允许网站来存储客户端的计算机上的信息，在...饼干的形式。这些cookies附加有一些信息。像饼干，它被创建时，当将它到期，谁设置cookie的名称等一个cookie看起来是这样的：

Browsers allow websites to store information on client's computer, in the form of... cookies. These cookies have some information attached to them. Like the name of the cookie, when was it created, when would it expire, who set the cookie etc. A cookie looks something like this:

的Cookie：cookiename =巧克力;域名= .bakery.com;路径= / [//; otherDdata]

因此​​，这是一个巧克力饼干。这应该是从 http://bakery.com 及其所有子域访问。

So this is a chocolate cookie. Which should be accessible from http://bakery.com and all of its subdomains.

这个cookie可能会包含一些敏感数据。在这种情况下，该数据是... 巧克力。高度敏感，因为你可以看到。

This cookie might contain some sensitive data. In this case, that data is... chocolate. Highly sensitive, as you can see.

所以浏览器保存此cookie。并且每当用户发出请求的域有该cookie是可访问的，则cookie将被发送到服务器进行该域。逍遥服务器。

So the browser stores this cookie. And whenever the user makes a request to a domain on which this cookie is accessible, the cookie would be sent to the server for that domain. Happy server.

这是一件好事。超爽方式为服务器来存储和检索对客户端的和的信息。
但问题是，这样使得 http://malicious-site.com 以这些Cookie发送到的 http://bakery.com ，的无需用户知道的例如，请考虑以下情形：

This is a good thing. Super cool way for the server to store and retrieve information on and of the client-side.
But the problem is that this allows http://malicious-site.com to send those cookies to http://bakery.com, without the user knowing! For example, consider the following scenario:

# malicious-site.com/attackpage

var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://bakery.com/order/new?deliveryAddress="address of malicious user"');
xhr.send();

如果您访问了恶意网站，上面的code执行，而同源策略是不存在，恶意用户将放置代表你的订单，并获得订单，在他的位置？你可能不喜欢这个东西。

If you visit the malicious site, and the above code executes, and same-origin policy was not there, the malicious user would place an order on behalf of you, and get the order at his place... and you might not like this thing.

这事，因为您的浏览器发送的巧克力饼干来 http://bakery.com ，这使的 http://bakery.com 认为的您的正在为新秩序的要求，明知的。但你不是。

This happened because your browser sent your chocolate cookie to http://bakery.com, which made http://bakery.com think that you are making the request for the new order, knowingly. But you aren't.

这是在平淡的话，CSRF攻击。 A十字，站点，提出了要求，并且请求是伪造的。 跨站请求伪造。它是行不通的，这要归功于同源策略。

This is, in plain words, a CSRF attack. A "cross" "site", made a "request", and the request was a "forged" one. "Cross Site Request Forgery". And it would not work, thanks to the same-origin policy.

如何相同的起源政策解决此问题？

它停止malicious-site.com提出请求到其他领域。简单的。

It stops the malicious-site.com to make requests to other domains. Simple.

在换句话说，浏览器会的没有的允许任何网站，使请求任何其他网站。它将prevent不同起源于通过这样的请求，相互交融，如AJAX。

In other words, the browser would not allow any site to make a request to any other site. It would prevent different origins from interacting with each other through such requests, like AJAX.

然而，从其他主机像图片，脚本，样式表，内部框架，表单提交等资源加载不受此限制。我们需要另一个墙来保护我们的面包店从恶意网站，使用<一个href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_$p$pvention_Cheat_Sheet#CSRF_$p$pvention_without_a_Synchronizer_Token">CSRF令牌的。

However, resource loading from other hosts like images, scripts, stylesheets, iframes, form submissions etc. are not subject to this limitation. We need another wall to protect our bakery from malicious site, by using CSRF Tokens.

CSRF令牌

如前所述，恶意网站仍然可以做这样的事情不违反同源策略：

As stated, malicious site can still do something like this without violating the same-origin policy:

<img src='http://bakery.com/order/new?deliveryAddress="address of malicious user"'/>

和浏览器将尝试从URL加载图像，从而导致一个GET请求到该URL发送所有的饼干。为了防止这种情况发生，我们需要一些服务器端的保护。

And the browser will try to load an image from that url, resulting in a GET request to that url sending all the cookies. To stop this from happening, we need some server side protection.

基本上，我们十分合适的熵随机的，独特的令牌用户的会话，它存储在服务器上，并且也将其发送到与形式的客户端。当提交表单时，客户端发送一个令牌随请求，服务器验证，如果该标记是有效还是无效。

Basically, we attach a random, unique token of suitable entropy to user's session, store it on the server, and also send it to the client with the form. When the form is submitted, client sends that token along with the request, and server verifies if that token is valid or not.

现在，我们已经做到了这一点，并恶意网站再次发送请求时，它总是会失败，因为没有可行的办法为恶意网站了解令牌用户的会话。

Now that we have done this, and malicious website sends the request again, it will always fail since there is no feasible way for malicious website to know the token for user's session.

当需要时，策略可以回避，当跨站请求是必需的。这就是所谓的的 CORS 的。跨地资源共享。

When required, the policy can be circumvented, when cross site requests are required. This is known as CORS. Cross Origin Resource Sharing.

该作品由具有域告诉浏览器寒意，并允许这样的请求。这种告诉的东西可以通过传递首部来完成。是这样的：

This works by having the "domains" to tell the browser to chill, and allow such requests. This "telling" thing can be done by passing a header. Something like:

访问控制 - 允许 - 产地：//逗号分隔的允许来源列表，或只是* 因此，如果 http://bakery.com 通过这个头到浏览器，并创建请求的 http://bakery.com 是present原点列表中，那么浏览器就会让要求走，随着饼干。

Access-Control-Allow-Origin: //comma separated allowed origins list, or just * So if http://bakery.com passes this header to the browser, and the page creating the request to http://bakery.com is present in the origin list, then the browser will let the request go, along with the cookies.

有根据该原点定义 ¹ 规则。例如，对于相同的域不同的端口是不一样的原点。因此，浏览器可能会拒绝这个请求，如果端口不同。与往常一样，我们的尊敬的 Internet Explorer的例外。 IE浏览器将所有的端口以同样的方式。这是非标和没有其他的浏览器的行为这种方式。 不要依赖此

There are rules according to which the origin is defined¹. For example, different ports for the same domain are not the same origin. So the browser might decline this request if the ports are different. As always, our dear Internet Explorer is exception to this. IE treats all ports the same way. This is non-standard and no other browser behaves this way. Do not rely on this.

JSON与填充的仅仅是一个的方式来规避同源策略，当CORS是不是一种选择。这是有风险的，一种不好的做法。避免使用这一点。

JSON with Padding is just a way to circumvent same-origin policy, when CORS is not an option. This is risky and a bad practice. Avoid using this.

什么此技术涉及正在请求到其它服务器像以下

What this technique involves is making a request to the other server like following:

＆LT;脚本SRC =htt​​p://badbakery.com/jsonpurl?callback=cake＆GT;＆LT; / SCRIPT＆GT;

由于同源策略并不prevent这个 ² 的请求，这个请求的响应将被加载到页面中。

Since same-origin policy does not prevent this² request, the response of this request will be loaded into the page.

此网址很可能会使用JSON内容作出回应。但是，仅仅包括JSON内容的网页上是不是要去帮助。这将导致错误着，当然。所以 http://badbakery.com 的接受一个回调参数，并修改JSON数据，将其发送包裹在任何被传递给回调参数。

This url would most probably respond with JSON content. But just including that JSON content on the page is not gonna help. It would result in an error, ofcourse. So http://badbakery.com accepts a callback parameter, and modifies the JSON data, sending it wrapped in whatever is passed to the callback parameter.

因此​​，

{用户：vuln，ACC：B4D455}

这是无效的JavaScript抛出一个错误，它会返回，

which is invalid JavaScript throwing an error, it would return,

蛋糕（{用户：vuln，ACC：B4D455}）;

这是有效的JavaScript，它会得到执行，可能会得到储存的地方根据蛋糕功能，使JavaScript的页面上的其余部分可以使用数据。

which is valid JavaScript, it would get executed, and probably get stored somewhere according to the cake function, so that the rest of the JavaScript on the page can use the data.

这主要用于通过API来的数据发送到其他领域。再次，这是一个不好的做法，是有风险的，并应严格避免。

This is mostly used by APIs to send data to other domains. Again, this is a bad practice, can be risky, and should be strictly avoided.

为什么JSONP不好？

首先，它是非常有限的。如果请求失败（AT-至少不是一个健全的方式）不能处理任何错误。您无法重试的要求，等等。

First of all, it is very much limited. You can't handle any errors if the request fails (at-least not in a sane way). You can't retry the request, etc.

这也需要你有一个蛋糕在全球的范围，这是不是很不错的功能。愿厨师救你，如果你需要执行不同的回调多个JSONP请求。这解决了暂时的职能由不同的库，但仍然做的事情的hackish的hackish的方式。

It also requires you to have a cake function in the global scope which is not very good. May the cooks save you if you need to execute multiple JSONP requests with different callbacks. This is solved by temporary functions by various libraries but is still a hackish way of doing something hackish.

最后，你是在DOM中插入随机的JavaScript code。如果你不是100％确保远程服务将返回安全的蛋糕，你不能靠这个。

Finally, you are inserting random JavaScript code in the DOM. If you aren't 100% sure that the remote service will return safe cakes, you can't rely on this.

^{1。 <一href="https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Definition_of_an_origin">https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Definition_of_an_origin}

^{2。 <一href="https://www.w3.org/Security/wiki/Same_Origin_Policy#Details">https://www.w3.org/Security/wiki/Same_Origin_Policy#Details}

其他值得读

<一个href="http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html">http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html

http://tool​​s.ietf.org/html/rfc3986 （抱歉：P）

<一个href="https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy">https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

<一个href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)">https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

这篇关于同源策略和CORS（跨域资源共享）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！