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.

(Source: iStock)
(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.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
US Formally Attributes SolarWinds Attack to Russian Intelligence Agency
Jai Vijayan, Contributing Writer,  4/15/2021
Dependency Problems Increase for Open Source Components
Robert Lemos, Contributing Writer,  4/14/2021
FBI Operation Remotely Removes Web Shells From Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/14/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-04-19
An out-of-bounds (OOB) memory access flaw was found in fs/f2fs/node.c in the f2fs module in the Linux kernel in versions before 5.12.0-rc4. A bounds check failure allows a local attacker to gain access to out-of-bounds memory leading to a system crash or a leak of internal kernel information. The hi...
PUBLISHED: 2021-04-19
A flaw was found in cifs-utils in versions before 6.13. A user when mounting a krb5 CIFS file system from within a container can use Kerberos credentials of the host. The highest threat from this vulnerability is to data confidentiality and integrity.
PUBLISHED: 2021-04-19
If Ethernet communication of the JTEKT Corporation TOYOPUC product series’ (TOYOPUC-PC10 Series: PC10G-CPU TCC-6353: All versions, PC10GE TCC-6464: All versions, PC10P TCC-6372: All versions, PC10P-DP TCC-6726: All versions, PC10P-DP-IO TCC-6752: All versions, PC10B-P TCC-6373: Al...
PUBLISHED: 2021-04-19
An exploitable SQL injection vulnerability exists in ‘getAssets.jsp’ page of OpenClinic GA 5.173.3. The serialnumber parameter in the getAssets.jsp page is vulnerable to unauthenticated SQL injection. An attacker can make an authenticated HTTP request to trigger...
PUBLISHED: 2021-04-19
GStreamer before 1.18.4 might access already-freed memory in error code paths when demuxing certain malformed Matroska files.