What is Same Origin Policy (SOP) | Same Origin Policy (SOP) Bypass

The Same Origin Policy is the security mechanism that is implemented in the browsers to restrict scripts contained on a page from accessing HTML data from another domain. Only it is permitted when the resource is requested from the same protocol, same host, and the same port.

Break the word "Same Origin Policy". Origin means from where the request is initiated for reading the data and the same origin means that the origin from where the request is initiated for reading the data should be the same as the origin from where that request needs to read the data.

Same Origin Policy = JavaScript code can access/read data that come ONLY from the Same Origin.

Origin of the source request from where the script tries to read the data = Origin of the response from where the data is to be read

Why do we need SOP? And How the browser works?

Let's take an example, you are logged into lazyhacker22bank.com, and at the same time, you are accessing lazyahcker22attacker.com in the same browser and in a new tab. If SOP doesn’t exist, a malicious script hosted on lazyahcker22attacker.com is free to read your information on lazyhacker22bank.com, since your browser would automatically include your lazyhacker22bank.com cookies in every request you send to lazyhacker22bank.com.

lazyahcker22attacker.com could do something like this:

1. Sends a GET request to lazyhacker22bank.com and tries to read personal_info using a script. Since you are logged in to lazyhacker22bank.com, the server could send back the HTML page containing your personal info page.

2. The attacker receives the returned HTML page.

3. An attacker can retrieve the CSRF tokens, private email addresses, addresses, and banking information parsed from the page.

This is why SOP we need a concept of SOP that will prevent the malicious script hosted on lazyahcker22attacker.com  to read the HTML data returned from lazyhacker22bank.com.

The SOP only allows a script on a domain to read the data from another domain when the domain, protocol, and port are the same. SOP is talking about the script and stopping the script to read the data from another origin.

Same Origin = Same protocol, Same Domain, and Same Port

How does SOP work when a domain tries to read data from another origin?

Let's take an example, when (https://lazyhacker22.blogspot.com/maliciousscript.html) script allows to read data:

In today's internet world we can't restrict everything because we need many resources from different domains like images, CSS, Media file, etc

How the SOP implemented in the browser prevent the reading of data?

The browser checks the origin before sending the request to any origin, if the origin is different or the same, if it's not the same, then the browser can't send the cookies of that origin and because of this request failed. 

"A" origin script tries to access "B" origin resources and before sending the request to "B" origin, the browser checks the origin, if the origin is not same, the browser can't send the cookie of "B" origin to the server of "B" origin when the request is performed by the script.

What is the exception or permitted by SOP?

Embedded resources are permitted by SOP. 

• Reading a Javascript file from another domain
• Reading of CSS, images, media, and fonts file from another domain
• iframe is allowed

SOP Bypass

XSS

You can bypass the SOP by XSS vulnerability. If the malicious javascript script can be loaded into the XSS vulnerable website, then the javascript will run in the context of that website. This means that if an attacker is able to execute the javascript on a page which is accessed by the victim, the malicious script can access the page resource and data and send that data to the attacker.

Misconfigured CORS

Misconfigured CORS can also bypass the SOP protection. We will read about this in detail in the next blog.

Access-Control-Allow-Origin: *

Access-Control-Allow-Credentials: true

JSONP (JSON with padding)
JSONP is created before CORS to provide cross-origin read access to Javascript or we can say it's an exception for SOP. Truly speaking, I have never found this issue. 

This attack is only possible when a vulnerable website is sending data in JSON format by using a callback function. Nowadays JSONP is not in use because modern browsers support CORS.

If you want to know more this is a good explanation of this vulnerability.

Exploitation: https://www.youtube.com/watch?v=9SqagAKYhy4

SOP bypass with Cache-Control header
Let's assume the condition that there are two subdomains "userinfo.bank.com" and "profile.bank.com". The "userinfo.bank.com" has a JSONP endpoint that returns sensitive data on the basis of cookies. The "userinfo.bank.com" only allows subdomains to read the data for which it's using a referer header check. 

Here the condition is that "userinfo.bank.com" also includes the Cache-Contol header. Example:

Cache-Control: private. In this case, the attacker needs to read the sensitive data from the browser cache.

Attack Scenario:

• The user visits "userinfo.bank.com" and login to the website.
• Now use click on "userinfo" and the user info fetch in the JSONP format which also contains the Cache-Control header.
• Now users visit "profile.bank.com" which needs userinfo data, as in the above steps the data is cached in the browser so the browser directly provides the cached data to "profile.bank.com".
• Now assume user visit to attacker's website "lazyhacker22.attacker.com" in the same browser.
• The malicious website contains a script that points to the JSONP endpoint of "userinfo.bank.com" 
• The browser returns the cached response to the script that is hosted on "lazyhacker22.attacker.com"

In this scenario, the referer header is never checked because the response comes from the cache.

Similar case work when CORS is misconfigured instead of JSONP. 

Protect against SOP bypass:

Cache-Control: no-store