Bypassing same origin policy (SOP) 2023
In this article we will learn about Bypassing same origin policy (SOP).
What is Bypassing same origin policy (SOP)?
Same origin policy is an important concept in the web application information security domain. In this policy, the web browser allows scripts contained in the first web page “A” to access data/resources in the second web page “B”, but only if both web pages have the same origin.
An origin is defined as a combination of a URI scheme, a hostname, and a port number. This policy prevents a malicious script on one page from accessing sensitive data on another web page through that page’s DOM (Document Object Model).
Let’s consider one example in a physical world scenario.
Imagine a school where all the students have different backgrounds. One class has many students, but they are not all related. If the guardian asks the school staff for the progress report of his son’s classmate, the school staff will reject the same as he has not proved himself for the same. Similarly, if a school has received a request to check a student’s progress report, it would first ensure that the applicant is a guardian/parent/next of kin of the student before providing the student’s details / progress report. This is closely related to the same origin policy (SOP) browser.
Now imagine a school that allowed anyone’s progress report to be accessed by any guardian from the outside world – that would be like a browser without SOP.
The same origin policy mechanism defines particular importance for modern web applications that rely heavily on HTTP cookies to maintain authenticated user sessions, as servers act on HTTP cookie information and expose sensitive information. On the client side, strict segregation must be maintained between content provided by unrelated sites to prevent loss of confidentiality or data integrity.
Same origin policy: Does it really matter?
Suppose you are logged into Gmail and visit a malicious website in the same browser but in a different tab. Without implementing the same origin policy, an attacker can gain access to your mail and other sensitive information using JavaScript. For example, read private mail, send fake mail, read your chats. Gmail also uses JavaScript to improve the user experience and save round-trip bandwidth, so it’s really that important that the browser can recognize that this JavaScript is trusted to access Gmail resources. This is where the same politics of origin comes into play. Now imagine the same scenario and replace Gmail with your online banking app – it could be worse.
Understand SOP with DOM: Same origin policy as document object model
When we talk about how JavaScript can access DOM policies, we consider the 3 parts of a URL which are HOSTNAME + SCHEME + PORT. If more than one application has the same hostname, scheme, and port and tries to access DOM data, access will be granted. However, Internet Explorer only validates the hostname + scheme before accessing. Internet Explorer does not care about PORT.
This is a traditional scenario that works well when accessing the same with a single origin. In many cases, multiple hosts within the same root domain accessing the source page’s DOM could be possible. Google is one example that takes a number of site verifications from a central authentication server.
For example, cart.httpsecure.org can authenticate via login.httpsecure.org. In such cases, sites can use the document.domain property to allow other sites in the same domain to interact with the DOM (Document Object Model). To allow code from cart.httpsecure.org to interact with login.httpsecure.org, the developer will need to set the document.domain property to the root of the domain on both sites.
ie document.domain = “httpsecure.org”
This means that anything in the httpsecure.org domain can access the DOM on the current page. When setting up this way, you should be aware that if you have deployed another site on the Internet, such as about.httpsecure.org, with some vulnerability, cart.httpsecure.org may also be vulnerable and can be accessed from that source.
Suppose an attacker is successfully able to upload some malicious code – then about.httpsecure.org would have the same level of access as the login page.
Understand SOP with CORS: Same origin policy combined with resource sharing between different resources
Cross-origin resource sharing (CORS) is a mechanism that allows many resources (eg fonts, JavaScript, etc.) on a web page to be requested from a domain other than the domain from which the resource originated.
Assume that an application uses XMLHttpRequest to send a request to another resource. In this case, you cannot read the response, but the request arrives at its destination. This is a very useful feature for cross-origin requests. SOP also prevents you from reading HTTP response headers and bodies. The best way to relax the SOP and allow resource-to-resource communication with XHR is to use resource-to-resource sharing (CORS).
If the httpsecure.org resource returns the following response header, then each subdomain of httpsecure.org can open a two-way communication channel with httpsecure.org:
[simple]
Access-Control-Allow-Origin: *.Httpsecure.org
Access-Control-Allow-Methods: OPTIONS, GET, POST, HEAD, PUT
Access-Control-Allow-Headers: X-custom
Access-Control-Allow-Credentials: true
[/simple]
In the response header above, the first line describes a two-way communication channel. The second describes that the request can be made using one of the OPTIONS, GET, POST, PUT, HEAD methods, possibly including the third-line x-custom header. Access-Control-Allow-Credentials: true specifies to allow authenticated communication with the resource.
Understand SOP with plugins: Same origin policy weds plugins
Note: If a plugin is installed for httpsecure.org:80, then it will only have access to httpsecure.org:80.
Many SOP implementations in Java, Adobe Reader, Flash and Silverlight are currently suffering from different bypass methods. Most of the browser plugins implement the SOP in their own way, such as some versions of Java consider two different domains to have the SOP if the IP is the same. This might have a devastating result in a virtual hosting environment, which host multiple applications with the same IP address.
If we talk about some plugins, such as Flash player and the PDF reader plugin, they have a long critical vulnerability history. Most of these issues allow an attacker to execute remote arbitrary code, which is far more critical than SOP bypass.
In Flash, you can use the method which allows you to manage cross-origin communication, which can be done using crossdomain.xml, which resides in the root of the application file and might have some of the following code.
[xml]
[/xml]
Using this code subdomain of httpsecure.org can achieve two-way communication with the application. Crossdomain.xml also supports Java and Silverlight plugins.
Understand SOP with UI redressing: Same origin policy weds UI redressing
UI redressing is a malicious technique of tricking a web user into clicking on something different from what the user perceives they are clicking on, thus potentially revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages.
UI redressing also known as clickjacking. For the attacker to bypass the SOP, it’s is little different. Some of these attacks rely on the fact the SOP was not enforced when performing the drag and drop function from the main window to an iframe.
Understand SOP with browser history: Same origin policy weds browser history
When we talk about browser history, the privacy of the end user always a concern. The same origin policy with browser history attack relies on traditional SOP implementation flaws, such as HTTP scheme having access to another scheme.
Bypass SOP in Java
Let talk about Java versions 1.7u17 and 1.6u45, which don’t enforce the SOP if two domains resolve to the same IP. Httpsecure.org and httpssecure.com resolve to the same IP (share hosting concept). A Java applet can issue cross-origin requests and read the responses.
In Java versions 6 and 7, both have an equal method of the URL object. Two hosts are considered equivalent if both host names can be resolved into the same IP address. This type of vulnerability in Java SOP implementation is a critical issue when exploiting in virtual hosting environments where potentially hundreds of domains are managed by the same server and resolved to the same IP.
The most important consideration concerning the privileges required by the applet to use the URL are BufferedReader and InputStreamReader objects. In Java 1.6, no user interaction is required to run the applet, however in 1.7, user permission is required to run the same due to the changes in the applet delivery mechanism implemented by Oracle Java 1.7. Now the user must explicitly use the click to play feature to run unsigned and signed applets.
This feature can be bypassed using IMMUNITY and led to a subsequent (now patched) bug CVE-2011-3546 found to bypass SOP in Java. Similarly, a SOP bypass was found in Adobe reader. One of the security researchers Neal Poole found one issue: “If the resource used to load an applet was replying with 301 or 302 redirect”, the applet origin was evaluated as the source of the redirection and not the destination.
Related article:Beginner methods & tools how to spaming phishing 2023
Have a look at the following code:
[plain]
[/plain]
Bypassing SOP in Adobe Reader
Adobe Reader has number of security critical bugs in its browser plugin. Most of the security vulnerabilities are arbitrary code execution due to traditional overflow problems. The Adobe Reader PDF parser understands JavaScript. This attribute is often used by malware to hide malicious code inside PDFs.
CVE-2013-0622, found by Billy Rios, Federico Lanusse and Mauro Gentile, allows bypassing the SOP (unpatched 11.0.0 version below). Where exploiting an open redirect which allows a foreign origin to access the origin of the redirect, the request that returns a 302 redirect response code is used to exploit the vulnerability.
If we talk about XXE Injection, it involves trying to inject malicious payloads into the request that accepts XML input as below:
[html]
]>
[/html]
In this XML parser that allows external entities, the value of &XXE is then replaced by the /etc/passwd. This technique can be used to bypass the SOP. It will load XE and the server will serve you with a 302 redirect response.
Bypassing SOP in Adobe Flash
Adobe Flash uses the crossdomain.xml file, which can control applications wherever Flash can receive data. We can set a restriction on this file to only trust mentioned sites as follows:
[html]
[/html]
By setting the allow-access-from domain, a Flash object loaded from any origin can send requests and read responses.
Bypassing SOP in Silverlight
Silverlight is a Microsoft plugin that uses the same origin policy in the same way as Flash does. However, it uses clientaccess-policy.xml codes shown below:
[html]
[/html]
Keep in mind that Flash and Silverlight have differences, such as Silverlight doesn’t segregate access between different origins based on scheme and port as Flash and CORS do. So, https://Httpsecure.org and http://Httpsecure.org consider the same origin policy.
Skipping SOP in Internet Explorer
Internet Explorer 8 or lower is vulnerable to SOP omission when implementing document.domain. The problem can be easily exploited by overriding the document object and then the domain property.
The following code shows the same:
[simple]
var document;
document = {};
document.domain = ‘httpsecure.org’;
alert(document.domain);
[/simple]
This code may cause an SOP Violation error code in the JavaScript console if you run it in the latest browser. The same will work in legacy/legacy Internet Explorer. Using XSS, this can be exploited to open two-way communication with other resources.
