Maybe I've got it all wrong, but I always thought that the cross-origin threat was that JS injected into my page would send sensitive data, like cookies or the contents of a form, to a third-party server. CORS seems primarily interested in making sure someone else's pages don't contact my server.
If I've got a malicious site, you can bet that I'm going to set the acceptable origin header to *. And, the W3C docs say that the origin can't be spoofed, unlike referer. I assume that's because the user-agent doesn't allow setting that header. But, if I was a hacker, one of the first things on my todo list would be to write my own browser, and then I could send whatever headers I please.
Wouldn't it make more sense that when I deliver a page to the browser, there is a header indicating what domains a request can be sent TO?
Joined: Nov 08, 2001
How is writing their own browser going to change anything. Only they would be the ones interacting with the site. It is to protect you as a user from people connecting to your bank account while you are on their site. I can do this now with any browser, I just need to change security settings so I can access any page ignoring the same origin policy.
CORS has nothing to do with protecting your page from other sites. CORS is basically giving other domains a key to your front door so they can come in and talk freely with your server.
Joined: Dec 04, 2008
Thanks for the comments. It seems like the world in general is loathe to describe the anatomy of a hack, so I'm left to my own imagination. And I'm trying to figure out a hack that would use real-time, programmatic access to a remote server, as opposed to store-the-credentials-and-come-back-later access.
Also, it seems to me that if the concept that the conceivers of CORS wanted was "Control of Origins of Requests to my Server", then that's what they should have named it, instead of Cross-Origin Resource Sharing. To me, the concept of "Cross-Origin" would apply to whose server my page can contact, in addition to whose page could contact my server.
Am I wrong that there is a whole family of possible hacks involving injecting JS into a page from foo.com that could then open an XmlHttpRequest to bar.com and send foo's cookies, etc., to bar? And, if so, wouldn't it be reasonable that there be a header foo could send with a page that listed allowable destinations for requests?