6

First apologies: This feels to me like a "dumb" question, and I expect I'll soon regret even asking it ...but I can't figure it out at the moment as my mind seems to be stuck in the wrong rut. So please bear with me and help me out:

My understanding is that "Same Origin" is a PITB for web services, and in response CORS loosens the restrictions just enough to make web services work reasonably, yet still provides decent security to the user. My question is exactly how does CORS do this?

Suppose the user visits website A, which provides code that makes web service requests to website Z. But I've broken into and subverted website Z, and made it into an attack site. I quickly made it respond positively to all CORS requests (header add Access-Control-Allow-Origin: "*"). Soon the user's computer is subverted by my attack from Z.

It seems to me the user never visited Z directly, knows nothing about Z's existence, and never "approved" Z. And it seems to me -even after the breakin becomes known- there's nothing website A can do to stop it (short of going offline itself:-). Wouldn't security concerns mandate A certifying Z, rather than Z certifying A? What am I missing?

Chuck Kollars
  • 1,995
  • 19
  • 17
  • 1
    A effectively certified Z by choosing to make webservice requests to it in the first place. – Barmar Mar 31 '13 at 04:56
  • http://www.html5rocks.com/en/tutorials/cors/ https://developers.google.com/accounts/docs/OAuth2 reading 4 when u cant sleep.... – Robert Rowntree Mar 31 '13 at 05:02
  • That thing is, as the kids say, "a lolorama". – qooplmao Mar 31 '13 at 05:06
  • 1
    So it seems the right CORS headers from a subverted site really does effectively cancel the browser's "Same Origin" policy altogether, right? So why bother getting browsers to implement CORS, rather than just getting them to relax their "Same Origin" policy? And isn't the use of OAuth effectively admitting CORS provides wildly inadequate user security? And if website A "certified" website Z (before its subversion) by providing Javascript code that uses Z, isn't CORS really completely irrelevant from a user's point of view? Does CORS really make as little sense to others as it does to me? – Chuck Kollars Mar 31 '13 at 19:17
  • See my answer here, which is somewhat related: http://stackoverflow.com/questions/15381105/cors-what-is-the-motivation-behind-introducing-preflight-requests/15385820#15385820 As Barmar says, A certifies Z by virtue of making the request. If Z is compromised, a client making same-origin requests to Z would be just as affected as cross-origin requests. CORS doesn't introduce anything dangerous in the case where the server is compromised. – monsur Apr 01 '13 at 03:09
  • Also note: CORS should not be used as a security mechanism! CORS is simply a way for the server to indicate that it expects cross-origin requests. User auth is orthogonal to CORS. – monsur Apr 01 '13 at 03:12
  • 1
    I fear we're talking about apples and oranges. A common concern - BUT NOT MINE HERE- is the security of the site providing the service (Z in this case) - no errors in charging, no repudiation of changes, no unauthorized access, etc. I'm concerned instead about the security of the browser user. The problem from the user's perspective is Z (a site he never actually went to and never gets a bill from and probably doesn't even know exists) put malware on his computer. – Chuck Kollars Apr 01 '13 at 18:30

2 Answers2

4

I was investigating this as well, as my thought process was akin to yours. Per my new understanding: CORS doesn't provide security, it circumvents it to provide functionality. Browsers in general don't allow cross-origin requests; if you go to shady.com, and there is a script there that tries to access bank.com using a cookie on your machine, shady.com's script would then be able to perform actions on bank.com using that cookie to impersonate you. To prevent this, bank.com would not mark it's APIs as CORS enabled, so that when shady.com's script begins the HTTP request, the browser itself prevents the request.

So same-origin protects users from themselves because they don't know what auth cookies are laying around; CORS allows a server that owns resources on behalf of the user to mark APIs as accessible from other sites' scripts, which will cause the browser to then ignore its own cross-origin protection policy.

(anyone that understands this better, please add or correct as needed!)

Rollie
  • 3,781
  • 2
  • 23
  • 42
3

CORS does nothing for security. It does allow someone selling web fonts to decide which websites get easy access to their fonts though. That's pretty much the only use case.

The user is just as unaware as they were before the introduction of CORS. And please remember that cross origin requests used to work before CORS (people often complain that you have to shim jQuery to get CORS support in IE... But in IE you could just make the request and get the response without any extra effort..it just worked).

Generally speaking the trust model is backwards. As others said you have implied trust by referencing some other site...so give me the freaking data!

AcklenX
  • 31
  • 3