Re: A Somewhat Critical View of SOP (Same Origin Policy)

> On 25 Sep 2015, at 06:53, Tony Arcieri <bascule@gmail.com> wrote:
> 
> On Wed, Sep 23, 2015 at 8:57 AM, Harry Halpin <hhalpin@w3.org> wrote:
> Supporters of such positions seem to have a lack of understanding of the 
> modern Web and/or basic cryptography and while to some extent basic 
> education can be done on Web-related mailing lists, I
> doubt many people find it is a productive use of their time given the
> large amount of high quality online courses out there and relatively
> important work that has to be done in terms of Web standards.
> 
> I have to agree with Harry Halpin here. I have been reluctant to further respond to this thread, but it seems like the people making the case that SOP needs to be abandoned do not understand SOP at a level requisite for participation in a web standards body.

Just to make it clear this is not my position. (David Longley has made a similar statement [1].)

I am trying to first locate SOP within a constellation of other concepts, such as Linkabilitly,
Privacy, Security, and Identity, and understand the logical basis of SOP. Concepts do not
appear all alone, they are allways related to other concepts that together play and interact
with each other.

This is well acknowledged in RFC 6454 [2] section 3.4.3

   Whenever user agents allow one origin to interact with resources from
   another origin, they invite security issues.  For example, the
   ability to display images from another origin leaks their height and
   width.  Similarly, the ability to send network requests to another
   origin gives rise to cross-site request forgery vulnerabilities [CSRF].  
   However, user agent implementors often balance these risks
   against the benefits of allowing the cross-origin interaction.  For
   example, an HTML user agent that blocked cross-origin network
   requests would prevent its users from following hyperlinks, a core
   feature of the web.


Linkeability in the web trumps SOP in this essential instance. This does not of course deny
the applicability of SOP in other areas. Perhaps if we analysed the logic of SOP would
we find that this is not a special case after all. The concepts are still quite vague.

> 
> There is one particular issue I think really needs to be called out, because I feel it represents what I'd consider a "web appsec 101" level understanding of how SOP works. I think this sort of egregious misunderstanding of SOP is the sort of thing that's frustrating Harry Halpin:
> 
> https://www.w3.org/Security/wiki/IG/a_view_on_SOP
> 
> Claim: "cookies: a single origin weak identity that lasts at most one year and that is controlled by the server"
> 
> This claim has been repeated by others in this thread (e.g. Henry Story)
> 
> Cookies do not follow SOP:
> 
> Cookies are shared across http:// and https:// origins unless the Secure flag is explicitly set. This flag is only present in the Set-Cookie header and is not transmitted back to the server in subsequent Cookie headers, so attackers who are able to MitM http:// traffic are able to set cookies which will be indistinguishably replayed to https:// origins without context as to the origin they were set on. This can be used for e.g. session fixation attacks. If cookies actually followed SOP, these sorts of attacks would not be possible.
> 
> Cookies support a Domain attribute that allows them to be set across origins. This means attackers who are able to gain access to one particular subdomain can perform similar attacks setting cookies at the domain level which will clobber existing cookies and be replayed by clients to other subdomains, again without the context of the origin they were actually set on. Again, if cookies actually followed SOP, these sorts of attacks would not be possible.

Thank you for helping me focus on this issue. I have changed the text on the wiki to:

[[
  cookies: specified by RFC6454 implement a fuzzy notion of single origin weak identity that in effect is mostly controlled by the server, with legal obligations in some countries to make the setting of cookies visible and controllable by the user. The server can specify cookies for one origin securely, but can set it more widely to subdomains and across protocols ( http and https ).
]]


Btw. It looks like FIDO also allows cross origin authentication that is not too far from this either. If you look at "FIDO AppID and Facet Specification v1.0" [3] it starts off with the following challenge, which I presume it aims to fix:

[[
while the FIDO approach is preferable for many reasons, it introduces several challenges.

 • What set of Web origins and native applications (facets) make up a single logical application and how can they be reliably identified?
 • How can we avoid making the user register a new key for each web browser or application on their device that accesses services controlled by the same target entity?
 • How can access to registered keys be shared without violating the security guarantees around application isolation and protection from malicious code that users expect on their devices?
 • How can a user roam credentials between multiple devices, each with a user-friendly Trusted Computing Base for FIDO?

This document describes how FIDO addresses these goals (where adequate platform mechanisms exist for enforcement) by allowing an application to declare a credential scope that crosses all the various facets it presents to the user.
]]

So here FIDO also makes an exception to SOP. 
If SOP where the only criteria in making decisions, then this could not be allowable. But clearly it is not. Other criteria come into play too.

> 
> This is the sort of foundational web appsec knowledge I think should be a minimum bar for participating in any W3C discussions to abandon SOP.

Again the discussion is not about abandoning SOP, but connecting it with work in privacy, identity, user interfaces etc...


> 
> --
> Tony Arcieri


[1] e.g. here: https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0174.html
[2] https://tools.ietf.org/html/rfc6454
[3] 
https://fidoalliance.org/wp-content/uploads/html/fido-appid-and-facets-v1.0-ps-20141208.html

Received on Friday, 25 September 2015 12:17:51 UTC