1

As I understand the "Same Origin Policy" is a browser security feature that aims to protect the user. It prevents scripts to load data from another webserver (typicall with ajax).

So esentially there are 3 actors:

  • The User in the Browser
  • The Original Website
  • The "other origin" Web Resource

Does it protect the user ? No: With CORS I can just allow any Origin on a malicious "Other origin" Web Resource

Does it protect the original Website? No: With CORS I can just allow any Origin on a malicious "Other origin" Web Resource

Does it protect the "other origin" Web Resource? No: A browser with Same Origin Policy disabled or a crafted request can be used to get the request trough anyway

I cannot get my head around that. What is the situation where the SOP help and which of these 3 actors does it protect in this situation.

Improve this question
1
4

It protects the legitimacy of the interaction between the user and the "original" website from malicious Javascript executed on the "other origin."

Suppose I am logged into a super-secret admin portal A. I've finished doing my admin work, so I decide to go off browsing and find myself on dodgy website B.

Dodgy website B executes some javascript that attempts to fetch some privileged data from A and ferry it off to a third party.

Enter Same Origin Policy. With the Same Origin Policy, the browser won't allow javascript to access that information.

And yes, the browser could simply not implement the Same Origin Policy, or the user could disable it, but that is not something that the dodgy folk over at Website B have control over.

Improve this answer
2
  • Thanks for your response. So the problem only exists because AJAX Requests actually include the cookies for the URL they call, enabling them to performing actions in my still logged in session. (Ignoring the fact that a session ID could also be passed as URL parameter on some websites). So actually in your scenario the role are switched: The dodgy website is becomes the "original website" while the "super-secret admin portal" becomes the "Other origin" web resource. Because "super secret admin portal" does not allow CORS, my browsers SOP protects me. – hefeteig Jul 19 '19 at 16:09
  • Note - have updated my answer as it was inaccurate. Same Origin Policy only typically protects the response data from a request, preventing the cross-origin request from reading response data. It does not typically (except under specific circumstances where a preflight request is made to check the policy) prevent the request from being made. So to prevent from malicious POST actions, anti-forgery tokens are a required additional measure. Same Origin Policy will, however, prevent an attacker from using a cross-origin request to get a valid anti-forgery token for subsequent attacks. – Ant P Jul 19 '19 at 16:32
0

I believe Same Origin Policy protects two things:

  • The website's cookies from being sent by a hacker. (e.g. hackersareus.com cannot send Stack Exchange a request with their cookies in it) This is a preflight request.
  • The website's public-facing pages from being scraped by a more scrupulous individual (e.g. stackdeck.com must use their server to scrape Stack Exchange - the browser won't do it for you) This is a non-preflighted, cookie-free request.

These two use cases are often confused with one another in my opinion.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.