5

There is a same origin policy in the browser to ensure that e.g. bad site won't read your data from Facebook. But it seems that the only problem that it tries to solve is that cookies are automatically sent with the request which authenticates the user (+ maybe some other authentication schemes like basic or maybe certificate).

So my question is: would we really need this policy if the browser would not send all the http auth details and cookies with this request automatically?

Maybe the best way is to allow cross-origin by default, but make sure that this information (cookie, http auth) is not transferred. In any case we can produce token based API now e.g. and so on if a cross-site request is required. And a 3d party caller would need to obtain a token the same way so that no CORS would be required.

Ilya Chernomordik
  • 2,197
  • 1
  • 21
  • 36
  • 1
    It also means that a JavaScript script included in a frame from a third-party website does not get to see the content of the original page that includes said frame. And probably a couple of other similar things. Essentially SOP indicates which resources can be trusted within a security context, which is important for all forms of client-side code executions. – Steve Dodier-Lazaro Feb 02 '16 at 16:12
  • Also are you sure this isn't a duplicate of http://security.stackexchange.com/questions/8264/why-is-the-same-origin-policy-so-important?rq=1? – Steve Dodier-Lazaro Feb 02 '16 at 16:13
  • This kills the internet. The business model of the internet is surveillance. Third party sites wouldn't be able to track you. – Neil McGuigan Feb 02 '16 at 18:48
  • @SteveDL - did you mean iframes and not classic browser frames? I don't think the latter provide any security boundaries. – Neil Smithline Feb 03 '16 at 00:43
  • 2
    @SteveDL this is not a duplicate since that questions says it's important because of cookies mostly. The main point of that question is to understand if cross-origin requests in ajax are blocked only for the reason of cookies? Why not to just not send the cookies in this case... – Ilya Chernomordik Feb 03 '16 at 08:21
  • @NeilSmithline they can track you with the appropriate SOP on the website that embeds the tracking tools. – Steve Dodier-Lazaro Feb 03 '16 at 11:36

2 Answers2

4

No, the Same Origin Policy also protects against:

  • Cross domain manipulation in the DOM (e.g. a page manipulating another page from another origin loaded in an IFrame).
  • The response from AJAX requests being read when the origins don't match.
  • Images loaded from other origins from being read into an HTML5 canvas.

So my question is: would we really need this policy if the browser would not send all the http auth details and cookies with this request automatically?

Yes we do need it for the above reasons.

It could work like that, but not now because of backwards compatibility reasons. It would break too many things suddenly changing a standard that most of the world's web is based upon.

In any case, what would happen in the case that the whole window is redirected? e.g. if there's as sensitive function that could be exploited via CSRF using the GET method, the attacker could simply redirect the whole page to https://example.com/delete_users in order to execute the attack.

How would the browser know not to send cookies in that situation? It appears the only thing you would achieve is to make the rules more complicated, and complexity is the enemy of security.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • Well, I guess that the latest problem is fixed by not allowing GET requests to such operations. I guess there are other issues with that like receiving that url in a mail where no same-origin will help you. – Ilya Chernomordik Feb 03 '16 at 12:10
3

To add to SilverlightFox' excellent answer:

Even if browsers did not send HTTP Auth headers and cookies with cross-domain requests (which is not practical because too many pages rely on this), cross-domain requests would still be dangerous, because a request may return private information even without authorization headers.

Essentially, the problem is that the client browser may have access to private resources using other authorization mechanisms. For example:

  • If the browser is in a private network behind a firewall, there may be private resources that are freely accessible from the private network, but not from outside.
  • If a resource authorizes access based on the client IP address or MAC address, the browser may have access because of the client computer it is running on.

In these situations, stripping out specific HTTP headers would not be enough.

As an aside, the idea of deliberately not sending cookies for certain requests has been implemented with SameSite cookies. SameSite cookies are not sent with cross-domain requests.

To avoid the backwards compatibility problems mentioned, SameSite cookies are "opt-in" - to create a SameSite cookie, the server must specify the SameSite when setting the cookie. Cookies set without this attribute continue to be sent for cross-domain requests, hence the Same-Origin policy remains important.

sleske
  • 1,622
  • 12
  • 22
  • Careful with terminology: _site_ has a very technical meaning in the context of the `SameSite` attribute. Using "cross-domain" instead of "cross-site" is misleading. – jub0bs Feb 04 '21 at 18:21