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.

Improve this question
3
  • 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, 2016 at 9: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, 2016 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 8, 2017 at 15:17

1 Answer 1

Reset to default
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

Improve this answer
4
  • 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 (crossorigin.me is exactly that). It is a bit different though, since if they get caught they could be IP-banned.
    – Nateowami
    Feb 8, 2017 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 8, 2017 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 9, 2017 at 1: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 9, 2017 at 12:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .