5

I'm doing some work with this right now and I have to say, it makes no sense at all to me! Basically, I have some CDN server which provides css, images ect for a site. For whatever reason, in order for my browser to stop blocking those resources with a CORS error, I had to have that server (the CDN) add the Access-Control-Allow-Origin header. But as far as I can tell that does absolutely nothing to increase security. Shouldn't the page I request which references those cross-domain resources be telling the browser it's safe to get stuff from the other domain? If that were a malicious domain wouldn't it just have the Access-Control-Allow-Origin set to * so that sites load their malicious responses (you don't have to answer that because obviously they would)?

So can someone explain how this mechanism/feature provides security? As far as I can tell the implementors fucked up and it actually does nothing. The header should be required from the page which references/requests cross-domain resources rather than from that domain being requested.

To be clear; if I request a page at domain A it would make sense for the response to include the Access-Control-Allow-Origin header white listing resources from domain B (Access-Control-Allow-Origin:.B.com), however it makes no sense at all for domain B to effectively white list itself by providing the header; Access-Control-Allow-Origin: which is how this is currently implemented. Can anyone clarify what the benefit of this feature is?

evanmcdonnal
  • 38,588
  • 13
  • 84
  • 107
  • Possible duplicate of [What are the security benefits of CORS preflight requests?](http://stackoverflow.com/questions/35424709/what-are-the-security-benefits-of-cors-preflight-requests) – dippas Apr 18 '16 at 22:44

3 Answers3

5

If I have a protected resource hosted on site A, but also control sites B, C, and D, I may want to use that resource on all of my sites but still prevent anyone else from using that resource on theirs. So I instruct my site A to send Access-Control-Allow-Origin: B, C, D along with all of its responses. It's up to the web browser itself to honor this and not serve the response to the underlying Javascript or whatever initiated the request if it didn't come from an allowed origin. Error handlers will be invoked instead. So it's really not for your security as much as it's an honor-system (all major browsers do this) access control method for servers.

Jacob See
  • 740
  • 6
  • 17
  • Oh so the idea is to restrict the use of your resources? Not to protect the thing requesting those resources? – evanmcdonnal Apr 18 '16 at 23:08
  • Yes, it's a part of Cross-Origin Resource Sharing (CORS) which does exactly what you said. Restricts/manages the use of your resources. CORS is a standardized way for relaxing the Same-Origin Policy in certain situations, which _does_ protect the end-user by preventing potentially malicious cross-domain requests in non-CORS compliant situations. – Jacob See Apr 18 '16 at 23:17
  • Once I started looking at it from the point of view of "I don't want random people to use my resources at domain B it started making sense" though I still see it as being pretty useless. It's not really consistent with how the internet works. If I want to steal your resources at domain B then I'll just type the url into my browser and copy/paste/save them and put them on my own server... No point in trying to stop someone from doing something that the system inherently allows you to do! – evanmcdonnal Apr 18 '16 at 23:22
  • It's true that it can still be pretty open. It's worth noting that a server using CORS can request credentials if set up to do so though! – Jacob See Apr 18 '16 at 23:27
2

Primarily Access-Control-Allow-Origin is about protecting data from leaking from one server (lets call it privateHomeServer.com) to another server (lets call it evil.com) via an unsuspecting user's web browser.

Consider this scenario:

You are on your home network browsing the web when you accidentally stumble onto evil.com. This web page contains malicious javascript that tries to look for web servers on your local home network and then sends their content back to evil.com. It does this by trying to open XMLHttpRequests on all local IP addresses (eg. 192.168.1.1, 192.168.1.2, .. 192.168.1.255) until it finds a web server.

If you are using an old web browser that isn't Access-Control-Allow-Origin aware or you have set Access-Control-Allow-Origin * on your privateHomeServer then your browser would happily retrieve the data from your privateHomeServer (which presumably you didn't bother passwording as it was safely behind your home firewall) and then handing that data to the malicious javascript which can then send the information on to the evil.com server.

On the other hand using an Access-Control-Allow-Origin aware browser and default web configuration on privateHomeServer (ie. not sending Access-Control-Allow-Origin *) your web browser would block the malicious javascript from seeing any data retrieved from privateHomeServer. So this way you are protected from such attacks unless you go out of your way to change the default configuration on your server.

Regarding the question:

Shouldn't the page I request which references those cross-domain resources be telling the browser it's safe to get stuff from the other domain?

The fact that your page contains code that is attempting to get resources from a particular server is implicitly telling the web browser that you believe the resources are safe to fetch. It wouldn't make sense to need to repeat this again elsewhere.

Peter S.
  • 21
  • 2
0

CORS makes only sense for Mashup content provider and nothing more.

Example: You are a provider of a embedded maps mashup service which requires a registration. Now you want to make sure that your ajax mashup map will only work for your registered users on their domains. Other domains should be excluded. Only for this reason CORS makes sense.

Another example: Someone misuse CORS for a REST-Service. The clever developer set up a ajax proxy and et voilà you can access from every domain on that service.

Such a ajax proxy would make no sense for a mashup, on the other way the CORS makes no sense for REST-Services, because you could bypass the restriction with a simple http-client.

Brain
  • 410
  • 7
  • 20