7

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 pain in the butt 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?

Koray Tugay
  • 22,894
  • 45
  • 188
  • 319
Chuck Kollars
  • 2,135
  • 20
  • 18
  • 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

3 Answers3

6

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
  • 4,391
  • 3
  • 33
  • 55
  • Regarding: _ 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._ .. : How can a browser prevent a request before knowing if the remote server allows cross origin requests or not? – Koray Tugay Aug 01 '21 at 19:29
  • @KorayTugay The browser will actually do an initial request to determine this before attempting to access said API - see https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request – Rollie Aug 05 '21 at 13:02
  • imo, it is very important to mention that preflight requests are done only for specific methods, specifically they are not made for GET and POST, which are the methods shaddy.com will probably try anyway.. – Koray Tugay Aug 05 '21 at 14:01
  • I didn't know that! I looked it up, and sounds like it is may send preflight for POST, etc, depending on the content type: https://stackoverflow.com/questions/39725955/why-is-there-no-preflight-in-cors-for-post-requests-with-standard-content-type – Rollie Aug 05 '21 at 14:27
4

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
  • 49
  • 1
  • 3
0

CORS protects the website that receives the request (Z in your example) against the one that makes the request (A in your example) by telling the user's browser who is or is not allowed to see the response of the request.

When a JavaScript application asks the browser to make a HTTP request to an origin that's different than its own, the browser does not know if there is mutual agreement between the two origins to make such calls. For sure, if the request come from origin A then A agrees (and A is responsible to its users if Z is malicious), but does Z, the recipient, agrees ? The only way for the browser to know is to ask Z, and it does that by actually doing the request. Unless Z explicitly allows A to receive the response, the browser will not let A's application read it.

You are right that the only effect of CORS is to relax the same-origin policy. Before that, cross-origin requests were permitted, and the browser would automatically include the cookies it has for the destination, that is, it would send an authenticated request to Z. This means that, without same-origin policy, A could browse Z just as if it was the user, see it's data, etc. Same-origin fixes this very severe security vulnerability, but because some services still need to use cross-origin requests sometimes, CORS was created.

Note that CORS does not prevent the request from being sent, so if A's JS app sends a request to Z ordering it to send all the user's money to some account, Z will receive this request with all the cookies in it. This is called a Cross-Site Request Forgery (CSRF). Interestingly, the main defence against this type of attack is based on CORS. It consists in requiring some secret value in the request (a “CSRF token”) that can only be obtained through a cross-origin request, which A cannot obtain if it's not on the authorized list of Z. Nowadays, same-site cookies can be used as well, they are easier to manage but don't work cross-origin.

Cédric Van Rompay
  • 2,489
  • 1
  • 18
  • 24