Meaning of SOP (same origin policy)

Question

What is the real meaning of SOP (Same Origin Policy)?

I know it means that the Javascript code from one origin cannot accuess resources from another origin. But what exactly does the word "resources" mean? For example:

1. Javascript code can access IMAGES from another site.
2. Javascript code cannot make ajax request to another side.

But when you use JSON padding, after completing the loading of a padded script tag, the 3rd party script will call your specified callback -- Javascript code from one site is invoking a method of Javascript code from another. Does this violate SOP?

Answer 1

Same Origin Policy is mainly intended to prevent scripts for other domains to perform AJAX (XMLHTTP) requests in the context of the loaded domain and also restricts sites of other domain to access sites resources like cookies, local storage etc. It is more like a standard specification formulated for security measures and every browser has its own way of implementing it by adhering to specifications.

By saying 'prevent scripts for other domains to perform AJAX (XMLHTTP) requests' I mean the cross-origin requests which don't belong to the same domain.

For example, domain.com and test.domain.com belong to the same domain and the test is subdomain, while test.domain2.com belongs to an entirely different domain.

Now let us consider its security implications:-

1.Let us say a website site1.com has an API call to update the password. When the user inputs the required data an HTTP call is made to the backend and the user's authenticity is validated with the session data contained in cookies.

2)Now with this being said, if the attacker creates a site named site2 and has a javascript code to make an HTTP call to site1's change password endpoint. By browsers default behavior it attaches all the cookie data it has for site1 to the request which makes the HTTP call successful thus allowing attackers to succeed.

3)To be able to mitigate this browsers implemented SOP, which dictates the browsers javascript engine to block any request to cross domains like from site2 to site1 for example, unless instructed to allow to do so.

4)Now in this growing modern world with microservice architectures and multiple subdomains, this will be very problematic. To get around this browsers support cross-origin requests if the API response says so with headers like Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Credentials, etc.

5)To put it forward when the ajax request is made from site2 to site1, the browsers check the API response headers and allows the request if any of these values are present in response:- Access-Control-Allow-Origin:* or Access-Control-Allow-Origin:site2.com or Access-Control-Allow-Origin:*.site2.com (wildcard entry)

6)With this being said there is a major loophole here, even if the sop policy blocks the request, it actually means that the browser blocks the site2 access to read the response data meaning the request was already made to the server. This scenario is only applicable to a few requests on specific conditions which doesn't trigger pre-flight options call. When the options call is made the browser will not allow the request to go through based on the header response in options call.

7)Now comes the second part to it which is Access-Control-Allow-Credentials. In the server response for options call, if the server sets the header to true all the confidential session data like Authorization header, secure cookies will be added to the cross-origin requests from site2 to site1.

Note:- This header is only added if Access-Control-Allow-Origin is very specific to a domain meaning it will not work for * value in the header. Is the Access-Control-Allow-Origin header is * then browsers SOP policy will kick in and blocks it from allowing the secure data if Access-Control-Allow-Credentials is set to true.

The SOP origin policy doesn't deal with image sources and external script includes. To be able to utilize control over those go through the Content Security Policy (CSP). Using it you could control access to external sites wrt to images, scripts, fonts, styles, etc. You would also be able to block unsafe-inline eval's in site like alert boxes to prevent some XSS attacks. This is new defacto standard and a lot of websites started implementing it.

To be able to prevent such attacks (CSRF attacks), websites also implement a csrf-token along with a form that changes on every state change. Even if attacker somehow makes the request from site2 to site1, the request will not go through as the server at site1 validates the csrf token along with the request, which the attacker cannot access through. Other measures would add origin-based validation if the origin header is present.

JSONP is designed to allow such a mechanism through callbacks.

Sorry for such a long answer and the topic is far bigger than this. This is just my own understanding of it and let me know if I am wrong anywhere.

Answer 2

JSONP gets around the Same Origin Policy by dynamically adding a script tag to the DOM and calling a predefined function with the remote web service's JSON data as the parameter. The tag is not subject to the same origin policy and therefore can request content cross-domain.

Just like how you can use Google's version of jQuery on your site without violating SOP, you can "include" a script tag that calls a predefined function on the data you receive back from a web service.

Answer 3

There are several types but if we don't specify:

SOP refers to a mechanism that governs the ability for JavaScript and other scripting languages to access DOM properties and methods across domains

Here you have an excellent description of different types of SOP.