5

As far as I understand, the Same Origin Policy exists to prevent authenticated requests from other origins.

So when a bad guy builds an evil website which tries to hijack the active authentication of my customers in order to manipulate or steal data on my server, my server can tell my customer's browser, that my server will not accept requests triggered from the evil website origin.

But I am wondering why the browser prohibits (SOP) all cross-domain requests when the receiving server does not respond with the correct CORS headers.

Question: Shouldn't it be safe to let the browser send 'zero-knowledge' requests without the authentication data, cookies, etc., that it knows from previous encounters with the domain? Like in incognito/anonymous browser mode or curl with a fresh cookie file?

That way cross domain communication would still work for servers without CORS headers and browsers would still prevent any authentication hijacking.

JepZ
  • 151
  • 2
  • 3
    How do you know what parts of a request are actually zero-knowledge? Is a GET request with a parameter "userid=sakjhgd7887h9hddh==" sending anything identifiable? Would the IP address which the request came from be enough to link it to someone? What about the user-agent string? – Matthew Dec 16 '16 at 09:43
  • 1
    @Matthew: The URL is set by the attacker, so more or less public knowledge. User-agent and ip should not be used for authentication. So the request should only contain the header fields it would contain if it had never visited the target domain before (+ those which have been manually added). So the browser would pretend it had zero knowledge about the requested domain. – JepZ Dec 16 '16 at 11:24
  • @Matthew If the attacker has enough information to prove authentication, then there's no reason he couldn't proxy it through his own server. It's the things the attacker can't see (primarily cookies) that a cross-origin request would allow him to use. – Nateowami Feb 08 '17 at 15:17

1 Answers1

1

No, they would not be.

Your assumption

CORS exists to prevent authentication to trusted domains

is wrong. Why? See my answer on this question

Community
  • 1
marstato
  • 2,237
  • 14
  • 11
  • In other words, you're saying the SOP is not just for the sake of security? The attacker could easily setup a proxy if all they want is the publicly-accessible data (https://crossorigin.me is exactly that). It is a bit different though, since if they get caught they could be IP-banned. – Nateowami Feb 08 '17 at 15:17
  • No, not exactly. SOP **is** primarily a security feature. CORS on the other hand is a means of *relaxing* the SOP in a very controlled way for the sake of information exchange. – marstato Feb 08 '17 at 15:52
  • OK, you're right. It should say "SOP exists to prevent authentication to trusted domains" (though I think sometimes "CORS" is misused in the general sense of cross-origin resource sharing restrictions). Are you saying the SOP exists in *only* to prevent using other domains' data, or that it is a major purpose that would not be served by zero-knowledge requests? It seems your premise is that cross-origin resources should not be shared (without permission), even in a zero-knowledge way. However, the web allows CSS files, JS, images, and much more to be shared without CORS headers. – Nateowami Feb 09 '17 at 01:35
  • @marstato you are right related to my use of the terms SOP (restriction) and CORS (relaxing of the restriction), I will correct that. But I think you miss the point about the rest of the question. In your other answer you argued that the SOP would protect my data from usage through other websites, but this is only true if the access to the API requires authentication and someone wants to hijack the credentials of your users. If there is no authentication involved the evil website could just use a non browser http-client to steal the data. – JepZ Feb 09 '17 at 12:10