Question

I was reading about CORS and I think the implementation is both simple and effective.

However, unless I m missing something, I think there s a big part missing from the spec. As I understand, it s the foreign site that decides, based on the origin of the request (and optionally including credentials), whether to allow access to its resources. This is fine.

But what if malicious code on the page wants to POST a user s sensitive information to a foreign site? The foreign site is obviously going to authenticate the request. Hence, again if I m not missing something, CORS actually makes it easier to steal sensitive information.

I think it would have made much more sense if the original site could also supply an immutable list of servers its page is allowed to access.

So the expanded sequence would be:

Supply a page with list of acceptable CORS servers (abc.com, xyz.com, etc)
Page wants to make an XHR request to abc.com - the browser allows this because it s in the allowed list and authentication proceeds as normal
Page wants to make an XHR request to malicious.com - request rejected locally (ie by the browser) because the server is not in the list.

I know that malicious code could still use JSONP to do its dirty work, but I would have thought that a complete implementation of CORS would imply the closing of the script tag multi-site loophole.

I also checked out the official CORS spec (http://www.w3.org/TR/cors) and could not find any mention of this issue.

Answer 1

But what if malicious code on the page wants to POST a user s sensitive information to a foreign site?

What about it? You can already do that without CORS. Even back as far as Netscape 2, you have always been able to transfer information to any third-party site through simple GET and POST requests caused by interfaces as simple as form.submit(), new Image or setting window.location.

If malicious code has access to sensitive information, you have already totally lost.

3) Page wants to make an XHR request to malicious.com - request rejected locally

Why would a page try to make an XHR request to a site it has not already whitelisted?

If you are trying to protect against the actions of malicious script injected due to XSS vulnerabilities, you are attempting to fix the symptom, not the cause.

Answer 2

Your worries are completely valid.

However, more worrisome is the fact that there doesn t need to be any malicious code present for this to be taken advantage of. There are a number of DOM-based cross-site scripting vulnerabilities that allow attackers to take advantage of the issue you described and insert malicious JavaScript into vulnerable webpages. The issue is more than just where data can be sent, but where data can be received from.

I talk about this in more detail here:

Answer 3

It seems to me that CORS is purely expanding what is possible, and trying to do it securely. I think this is clearly a conservative move. Making a stricter cross domain policy on other tags (script/image) while being more secure, would break a lot of existing code, and make it much more difficult to adopt the new technology. Hopefully, something will be done to close that security hole, but I think they need to make sure its an easy transition first.

Answer 4

I also checked out the official CORS spec and could not find any mention of this issue.

Right. The CORS specification is solving a completely different problem. You re mistaken that it makes the problem worse - it makes the problem neither better nor worse, because once a malicious script is running on your page it can already send the data anywhere.

The good news, though, is that there is a widely-implemented specification that addresses this problem: the Content-Security-Policy. It allows you to instruct the browser to place limits on what your page can do.

For example, you can tell the browser not to execute any inline scripts, which will immediately defeat many XSS attacks. Or—as you ve requested here—you can explicitly tell the browser which domains the page is allowed to contact.

Answer 5

The problem isn t that a site can access another sites resources that it already had access to. The problem is one of domain -- If I m using a browser at my company, and an ajax script maliciously decides to try out 10.0.0.1 (potentially my gateway), it may have access simply because the request is now coming from my computer (perhaps 10.0.0.2).

So the solution -- CORS. I m not saying its the best, but is solves this issue.

1) If the gateway can t return back the bobthehacker.com accepted origin header, the request is rejected by the browser. This handles old or unprepared servers.

2) If the gateway only allows items from the myinternaldomain.com domain, it will reject an ORIGIN of bobthehacker.com . In the SIMPLE CORS case, it will actually still return the results. By default; you can configure the server to not even do that. Then the results are discarded without being loaded by the browser.

3) Finally, even if it would accept certain domains, you have some control over the headers that are accepted and rejected to make the request from those sites conform to a certain shape.

Note -- the ORIGIN and OPTIONS headers are controlled by the requester -- obviously someone creating their own HTTP request can put whatever they want in there. However a modern CORS compliant browser WONT do that. It is the Browser that controls the interaction. The browser is preventing bobthehacker.com from accessing the gateway. That is the part you are missing.

Answer 6

I share David s concerns. Security must be built layer by layer and a white list served by the origin server seems to be a good approach.

Plus, this white list can be used to close existing loopholes (forms, script tag, etc...), it s safe to assume that a server serving the white list is designed to avoid back compatibility issues.

友情链接