0

I have read some articles on Same Origin Policy and CORS and still doesn't understand well the security that it brings to the user.

The Same Origin Policy gives a true valuable security, preventing a site from an origin from accessing some webpage content on another website. Thus preventing the threat of having the content of a iframe accessed by the script of the container, possibly faked/phishing website.

But here comes AJAX and CORS. CORS gives the ability for the server to control which origins can access it. But, at the end, it is the browser which stops the request if not allowed, after headers handcheck.

So, imagine you get some malicious website myphishing.com. You want to show information from another trusted website mybank.com through AJAX request to this site. This one is protected by well configured CORS headers only allowing request from mybank.com origin. What if, me author of myphising.com, relay all requests to mybank.com by a proxy that alter headers in both request and response way to fake client browser and bank server? It seems one can change the origin header in the request for a mybank.com one, and change the CORS response headers to make the browser think myphishing.com is allowed to make the request. Headers handcheck passed, you can then send the request and get the response with similar headers substitution tricks.

Perhaps I'm totally misleaded, but I would be very pleased if someone could show me where I have misunderstand the whole thing.

Possible duplicate but I didn't find my answer here: What is the threat model for the same origin policy?.

Cœur
  • 37,241
  • 25
  • 195
  • 267
Doc Davluz
  • 4,154
  • 5
  • 30
  • 32

1 Answers1

2

What if, me author of myphising.com, relay all requests to mybank.com by a proxy that alter headers in both request and response way to fake client browser and bank server?

You could do that anyway, CORS or no CORS.

If the request is coming from your proxy, however, then it has no way to know what credentials the browser would have sent to the server if the request was coming from the browser.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • Ok, so CORS is only valuable with credential security based server: HTTPS or cookies? I recall that cookies can also be altered by proxy, so not sure if it is enough secure. And my question is still valid: in what way Same Origin Policy with CORS ensure a trustfull security? – Doc Davluz Feb 13 '14 at 14:49
  • The Same Origin Policy is mostly only valuable when dealing with personalised data. It stops Mallory's website from giving Alice's browser JavaScript that gets Alice's data from Bob's website and gives it to Mallory. CORS is there to turn off the Same Origin Policy when Bob wants to make data (which may or may not be personalised) sharable to other sites. – Quentin Feb 13 '14 at 14:54
  • I get that. But what if Mallory proxifies all requests from Alice to Bob through its own proxy? Is it an impossible scenario or how is it prevented by CORS? – Doc Davluz Feb 13 '14 at 15:04
  • Then either (1) They have persuaded Alice to reconfigure her network settings and there is no hope for Alice or (2) They are giving Alice's URLs on Mallory's server so it won't send credentials that it knows are for Bob's server. – Quentin Feb 13 '14 at 15:07
  • Ok. Thanks for your highlights. It confirms what I think: CORS is only usefull if you setup along a credentials system for you service. – Doc Davluz Feb 13 '14 at 15:19
  • No. The Same Origin Policy is only useful if you have a credentials system. CORS is useful for any data you want to expose to other websites, including data that doesn't need protection. – Quentin Feb 13 '14 at 15:24
  • But both things comes in pair: is not CORS a way to circumvent Same Origin Policy restrictions for AJAX calls? I think I still doesn't get the point… Would need a detailed explanation, will seek for it. – Doc Davluz Feb 13 '14 at 15:47