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

12/24/2018
09:35 AM
Larry Loeb
Larry Loeb
Larry Loeb
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
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
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15208
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
CVE-2020-15209
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
CVE-2020-15210
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
CVE-2020-15211
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
CVE-2020-15212
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...