Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

09:35 AM
Larry Loeb
Larry Loeb
Larry Loeb

SOP Story: Why Protecting Web Browsers Remains a Security Cornerstone

One of the oldest ways to protect content on the web is SOP. However, it's not always implemented in the same way on all browsers. This can complicate one of the main cornerstones of Internet security.

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":

    1) Reading (bit-by-bit copy) of resources from Origin "B": Deny
    2) Writing to Origin "B": Limit
    3) Execution of resources from Origin "B": Allow

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.

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.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
New 'Nanodegree' Program Provides Hands-On Cybersecurity Training
Nicole Ferraro, Contributing Writer,  8/3/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, the markdown parser could disclose hidden file existence.
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, a user without permission is able to create an article draft.
PUBLISHED: 2020-08-08
JetBrains YouTrack before 2020.2.8873 is vulnerable to SSRF in the Workflow component.
PUBLISHED: 2020-08-08
In JetBrains Kotlin before 1.4.0, there is a script-cache privilege escalation vulnerability due to kotlin-main-kts cached scripts in the system temp directory, which is shared by all users by default.
PUBLISHED: 2020-08-08
In JetBrains TeamCity before 2020.1, users with the Modify Group permission can elevate other users' privileges.