SOP Story: Why Protecting Web Browsers Remains a Security Cornerstone

Preventing the content of one website from interfering with the content of another site has been a long-standing goal of those who want to make the web more secure and safe to use.

One of the ways this has been addressed is in something called the Same-Origin Policy (SOP). A recent study shows that SOP and how it protects users doesn't get implemented the same way in all browsers. What does this mean for browser security?

To understand the differences, let's examine how browser makers apply SOP.

The big view
SOP is a compilation of the ways that a browser should act so that one site cannot get access to the elements of another by using sneaky means. It guides how a browser should respond to content requested from another site.

SOP can be conceptualized by the use of the Read, Write, Execute (RWX) permissions model of Unix and NTFS. If there is a web page sitting at an origin "A," a SOP implementation in a browser will give it the following permissions for a web page of origin "B":

Those are the basic operations that may occur between resources of differing origins within the browser. The exact methods of implementation do have some subtleties, however.

SOP-DOMThere is a subset of the SOP rules that deal with interaction between a host document and an embedded document called SOP-DOM, with DOM standing for document object model.

DOM is the standardized application programming interface (API) for scripts running in a browser to interact with the HTML document. It defines the "environment" where a script operates.

(Source: iStock)

Unlike other rules, there has never been definitive SOP-DOM agreement established. This has led to differences in how SOP-DOM is implemented in each browser, making for a situation that allows elements to have differing access rights, depending on which browser are viewed.

SOP-DOM is usually thought of as a boolean switch, which will allow interactions in the same-origin case or blocks access in case of different web origins. But it is not that simple. The IMG element may block almost all access even in the same-origin case, but the script element will allow full read and write access (in one direction) even in the case of different origins.

There is a mechanism called Cross-Origin Resource Sharing (CORS) that is supposed to help with how a browser accesses data from different sites. But because of interactions between web APIs CORS may not always be invoked, or invoked incorrectly.

SOP attacksThere are many kinds of attacks that can be launched cross-origin. A cross-site scripting (XSS) attack, for example, would try to get malicious content rendered in a browser by getting around SOP policies and methods. XSS can happen when one site doesn't properly validate the input received in a URL or a POST body to eliminate scripts that may be embedded.

There is also a Cross Site Request Forgery (CSRF) attack, where a web browser gives cookies and other authentication information to servers without regard to the context of that communication. This allows for simple impersonation of a valid user by an attacker's webpage which uses the user's browser as part of the attack.

There are conceptually simpler attacks. A site might blindly trust the value of a URL parameter (e.g. IsAdmin=True) and expose itself to abuse.

So, SOP is best utilized in the mediation of site-to-site attacks.

Multimedia embedding Developer Jake Archibold discoveredthat Firefox and Microsoft's Edge browser were making requests for multimedia content from different domains via the "range" parameter. This syntax was not covered by SOP, but it was a useful way to do things. Content sharing was done in this way by some browsers and then was copied by other browser creators.

But this approach of multimedia fetching means that malware data could be stuffed into, say, an audio element and that audio retrieved without further CORS checks. This is all because the functionality of the range parameter was never formally standardized.

In general, headers have a standardized formal structure, but how a browser should handle them -- what parts it should act on, what parts it should filter -- is up to the browser. And this is what messes up range's functionality.

Range actually calls the fetch function, which sees a header (range) that isn't allowed in no-CORS requests, and silently removes it. So, the server never sees the range header and responds with a standard response. Boom, CORS is by-passed.

Some browser data calls are treated as special cases. Cross-origin loaded JavaScript code (via script src="...") is one. It is treated as if it had been loaded from the same origin as the page it is embedded in. No access restrictions are imposed by the SOP. Full read/write permissions are available to the document that embeds it, and full execution is permitted.

This is a case fraught with dangerous possibilities. An overwrite could change the functionality of the loaded code, for example.

CSS code from an external source can only be read in most browsers if certain CORS values are set. But here again, Microsoft does things differently. Internet Explorer and Edge allow read access in every case. This allows CSS rules to be read cross-origin while other browsers will stop that from happening.

Comparing browsers In a paper presented at the 2017 Usenix security conference, researchers evaluated how browsers compare to each other when they are using materials from other sites.

Out of the 544 test cases they came up with, 129 of the cases were found to differ in behavior across ten tested browsers (23.71%).

In their research, they found major areas of difference in how things were handled. Thirty-five percent of the identified differences could be attributed to how the browsers processed the canvas tag along with PNG/SVG images.

Also, over 51% of the test cases show different behaviors because of how the handling of the link tag is done. As the researchers note: "Nearly all the cases have different CORS implementations. CORS thus shows that a relatively new and complex technology leads to different interpretations of 'well-known' web concepts like SOP."

SOP is a cornerstone of web security. It provides a way that web pages may share, but also provides a way to keep the parts of them that need to be withheld private.

Related posts:

— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.