同源策略和 CORS(跨源资源共享) [英] Same origin Policy and CORS (Cross-origin resource sharing)
问题描述
我试图理解 CORS.根据我的理解，这是一种在浏览器中实现的安全机制，可以避免对域的任何 AJAX 请求，而不是用户打开的请求(在 url 中指定).
现在，由于这个限制，许多 CORS 被实施来使网站能够进行跨源请求.但根据我的理解，实施 CORS 违背了同源策略"的安全目的；标准操作程序.
CORS 只是为了提供对哪个请求服务器想要提供服务的额外控制.也许它可以避免垃圾邮件发送者.
来自 将此标头传递给浏览器，并且创建请求的页面http://bakery.com 出现在源列表中，然后浏览器将放行请求，同时饼干.
有定义原点的规则1.例如，同一个域的不同端口就不是同源的.因此，如果端口不同，浏览器可能会拒绝此请求.与往常一样，我们亲爱的 Internet Explorer 是个例外.IE 以相同的方式处理所有端口.这是非标准，没有其他浏览器有这种行为.不要依赖这个.
JSONP
JSON with Padding 只是一种规避同源策略的方法，当 CORS 不是一个选项时.这是有风险的，也是一种不好的做法.避免使用它.
该技术涉及向其他服务器发出请求，如下所示:
由于同源策略不会阻止这个2请求，这个请求的响应将被加载到页面中.
这个 url 很可能会以 JSON 内容响应.但仅在页面上包含该 JSON 内容无济于事.当然，这会导致错误.所以 http://badbakery.com 接受一个回调参数，并修改 JSON 数据，将它包裹在传递的任何内容中发送到回调参数.
所以，而不是返回，
{ user: "vuln", acc: "B4D455";}这是无效的 JavaScript 抛出错误，它会返回，
cake({user: "vuln", acc:"B4D455"});这是有效的 JavaScript，它会被执行，并可能根据 cake 函数存储在某处，以便页面上的其余 JavaScript 可以使用数据.
这主要由 API 用于将数据发送到其他域.同样，这是一种不好的做法，可能有风险，应严格避免.
为什么 JSONP 不好?
首先，它非常有限.如果请求失败(至少不是以理智的方式)，您将无法处理任何错误.您无法重试请求等
它还要求你在 global 范围内有一个 cake 函数，这不是很好.如果您需要使用不同的回调来执行多个 JSONP 请求，那么厨师们可能会救您.这是由各种库通过临时函数解决的，但仍然是一种黑客行为.
最后，您将在 DOM 中插入随机的 JavaScript 代码.如果您不能 100% 确定远程服务会返回安全的蛋糕，则不能依赖于此.
参考资料
1.https://developer.mozilla.org/en-美国/docs/Web/Security/Same-origin_policy#Definition_of_an_origin
2.https://www.w3.org/Security/wiki/Same_Origin_Policy#Details
其他值得一读
<块引用>http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html
https://www.rfc-editor.org/rfc/rfc3986(对不起:p)
https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
https://www.owasp.org/index.php/跨站点_请求_伪造_(CSRF)
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).
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 is just to provide extra control over which request server wants to serve. Maybe it can avoid spammers.
From Wikipedia:
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:
Origin: http://www.example-social-network.com
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:
Access-Control-Allow-Origin: http://www.example-social-network.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.
What am i missing here? what is the the intend of CORS to secure the server vs secure the client.
Same-origin policy
What is it?
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.
How does a CSRF attack work?
Browsers allow websites to store information on a client's computer, in the form of cookies. These cookies have some information attached to them, like the name of the cookie, when it was created, when it will expire, who set the cookie etc. A cookie looks something like this:
Cookie: cookiename=chocolate; Domain=.bakery.com; Path=/ [// ;otherDdata]
So this is a chocolate cookie, which should be accessible from http://bakery.com and all of its subdomains.
This cookie might contain some sensitive data. In this case, that data is... chocolate. Highly sensitive, as you can see.
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.
This is a good thing. Super cool way for the server to store and retrieve information on and from 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();
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.
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.
This is, in plain words, a CSRF attack. A forged request was made across sites. "Cross Site Request Forgery". And it would not work, thanks to the same-origin policy.
How does Same-origin policy solve this?
It stops the malicious-site.com from making requests to other domains. Simple.
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.
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 Tokens
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"'/>
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 the 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 the 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" tell the browser to chill, and allow such requests. This "telling" thing can be done by passing a header. Something like:
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.
There are rules according to which the origin is defined1. 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 the 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.
JSONP
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:
<script src="http://badbakery.com/jsonpurl?callback=cake"></script>
Since same-origin policy does not prevent this2 request, the response of this request will be loaded into the page.
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.
So instead of returning,
{ user: "vuln", acc: "B4D455" }
which is invalid JavaScript throwing an error, it would return,
cake({user: "vuln", acc:"B4D455"});
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.
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.
Why is JSONP bad?
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.
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.
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.
References
1. https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Definition_of_an_origin
2. https://www.w3.org/Security/wiki/Same_Origin_Policy#Details
Other worthy reads
http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html
https://www.rfc-editor.org/rfc/rfc3986 (sorry :p)
https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
这篇关于同源策略和 CORS(跨源资源共享)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
