Main Content

Heya - HollyGraceful here, I make all of this content in my spare time, like it? Please support me :)
You can donate via Bitcoin or Patreon!

SOP: Same-Origin Policy Basics

Same-Origin Policy (SOP) is a critical part of the security implemented within a web browser. It’s the part of your browser’s security system that prevents malicious pages from reading confidential information from other sites. So thepiratebay.com can’t read data from barclays.com because it’s blocked by SOP.

The way that it works simply, is that pages of different origins can send requests to other domains, but not process their responses. Certain items aren’t covered by SOP, such as images and scripts – this is because these are considered assets to be used within an application and not considered to affect the security of that application.

Scripts, such as JavaScript, that are requested from a different domain execute within the context of the requesting domain – so they don’t affect the other domain’s security. Therefore http://malicious.site/ can request a script from http://confidential.site/ but the script will execute within malicious.site so they can’t steal cookies, session tokens or confidential data from confidential.site. Easy!

For a site to be considered the “same-origin” it must have the same hostname, protocol and port.

So http://confidential.site and http://malicious.site are obviously considered a different origin, but so are: http://confidential.site and https://confidential.site.

 

It’s important to note however that the request can still be generated and sent – and that it will be processed by the remote server, but that the browser prevents the different origin application from processing the response. Sometimes there are requests that don’t require the response for an attacker to benefit from them. For example a transfer from one bank account to anther that has no origin protection can still be forged from a malicious site! This is an attack known as Cross-Origin Request Forgery (CSRF) and affects functions on websites where the response is not an important aspect of the function itself.

So where a site simply requires the amount and destination account to transfer funds, such as: http://bank.site/?amount=1000&account=22984098 where the response when successfully processed being just: “Success”. The attacker can forge this request and transmit it when a victim visits the malicious site, as the response is simple “Success” and the request is processed regardless of whether SOP blocks the response or not an attacker can steal funds. More information on this type of attach can be found in the article: What Is Cross-site Request Forgery?