W3C home > Mailing lists > Public > public-web-security@w3.org > September 2015

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

From: Brad Hill <hillbrad@gmail.com>
Date: Tue, 29 Sep 2015 16:40:39 +0000
Message-ID: <CAEeYn8g6AziOcWCA3JCZW+equ2KaeVDPtUNmiJ8p0ugU-q5HEQ@mail.gmail.com>
To: Henry Story <henry.story@co-operating.systems>, Jeff Hodges <jeff.hodges@paypal.com>
Cc: Dave Longley Longley <dlongley@digitalbazaar.com>, Dave Raggett <dsr@w3.org>, Carvalho Melvin <melvincarvalho@gmail.com>, Martin Paljak <martin.paljak@ria.ee>, "public-web-security@w3.org" <public-web-security@w3.org>, WebAppSec WG <public-webappsec@w3.org>, GALINDO Virginie <Virginie.Galindo@gemalto.com>
Within the context of Web Origins, FIDO uses approximately the same scoping
rules as cookies. That is to say, key scope must stay within a delegated
label or its children and not cross delegation points identified by the
public suffix list.  "www.example.com" and "register.example.com" can each
set a cookie for "example.com" which the other can see, but subdomains of "
hosting.example.com" cannot set cookies at or beyond that label if it is
designated as a public suffix.  This provides some limited usability
affordances within the existing information flow boundaries of the web
security model while mostly that keys are scoped to a single logical
organization as defined by domain registrars.

On Tue, Sep 29, 2015 at 5:50 AM Henry Story
<henry.story@co-operating.systems> wrote:

> On 29 Sep 2015, at 00:23, Hodges, Jeff <jeff.hodges@paypal.com> wrote:
> the claims made in https://www.w3.org/Security/wiki/IG/a_view_on_SOP#FIDO are
> incorrect — perhaps whoever wrote them did not read the spec in question
> carefully.  here's what I just entered in that wiki section:
> _THE ABOVE CLAIM IS INCORRECT_ "such as other web origins within the same
> DNS zone of control of the AppID's origin" essentially means that what is
> colloquially known as "domain lowering" (as in what is colloquially known
> as the "cookie same origin policy") is used to determine if a given web
> origin is "within the same DNS zone of control of the AppID's origin". How
> to determine this is specified in <
> https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-appid-and-facets-v1.0-ps-20141208.html#determining-if-a-caller-s-facetid-is-authorized-for-an-appid>
> Step 14. See also 'HTTP cookie processing algorithm in terms of Same Origin
> Policy and “effective Top Level Domains (eTLDs)” aka “Public Suffixes”' <
> http://identitymeme.org/http-cookie-processing-algorithm-etlds/>. =JeffH
> Thanks Jeff for the input.
> I think this suggests that we need to look more carefully at the
> definition of SOP.
> I should add a section at the top of the wiki on that.
> Tony Arcieri has put forward a strict defintion of Same Origin in his mail
> today [1].
> For him two origins are the same if and only if they have the same scheme,
> domain
> and port. "Anything besides this is not following SOP." he adds. This
> reasoning
> leads him to the conclusion that cookies are broken. "RFC-6265 is in
> effect telling
> us that cookies are broken because a long time ago Netscape made some bad
> decisions."
> Tony's definition is what I would call strict Same Origin. [2] In
> opposition to this you want
> to define a weaker notion of Same Origin, following the Cookie Processing
> Algorithm
> you cite, and for which there are some nice examples in the FIDO Facets
> document [3].
> It is clear that the weaker notion of same origin has a wider identity
> criterion, that
> aims to be more flexible in its notion of origin, in that a number of
> Origin URIs identify
> the same agent.
> But according to Tony Acieri this weaker notion is not a notion of same
> origin at all.
> If so, and if he does not wish to also argue that FIDO is broken, then we
> need to understand
> what enables FIDO to expand from the notion of origin, or put in Alex's
> language how FIDO
> allows trust between origins to work.  There are a number of ways I can
> think of arguing
> this point.
> Henry
> [1]
> https://lists.w3.org/Archives/Public/public-web-security/2015Sep/0118.html
> [2] I made this distinction in the Cookies section, but should move this
> up to a SOP
>    definitions section
>    https://www.w3.org/Security/wiki/IG/a_view_on_SOP#Cookies
> [3]
> https://fidoalliance.org/wp-content/uploads/html/fido-appid-and-facets-v1.0-ps-20141208.html#appid-example-1
>   Mind you I don't quite understand why
>     https://www.example.com/appID
> can have
>    https://register.example.com
> as an equivalent weak Same Origin, but
>   https://companyA.hosting.example.com/appID
> cannot have
>   https://companyB.hosting.example.com
> as an equivalent same origin. ( The result makes sense, but the rules are
> not easy to follow )
> On 9/28/15, 12:47 PM, "GALINDO Virginie" <Virginie.Galindo@gemalto.com>
> wrote:
> Henry,
> I believe that the wiki page should start by  writing use cases, and not
> re-explaning SOP cons and your technical vision. If you want to trigger
> collaborative thinking, thanks for exposing:
> - Use case,
> - What feature in your use cases can't be achieved with today's technical
> rules.
> And then we will be able to have technical discussions about potentiel
> solutions.
> Regards
> Virginie
> ---- Henry Story a écrit ----
> > On 25 Sep 2015, at 15:38, GALINDO Virginie <Virginie.GALINDO@gemalto.com>
> wrote:
> >
> > Thanks for completing your use case on the wiki dedicated to that topic,
> guys !
> > https://www.w3.org/Security/wiki/IG/a_view_on_SOP
> >
> > Regards,
> > Virginie
> Thanks Virginie for the great idea of putting up this wiki. Mailing list
> discussions are very educational if one follows them with great care, but
> it is very difficult for people who jump in from the outside in mid
> conversation
> or who are following from the sidelines to understand what if anything has
> been gained by the discussion.
> I have brought together a lot of what I have learnt about SOP with many
> references to IETF and W3C specs, pointers to new evolutions in the
> webapp(sec)
> groups, and discussion with community members on the wiki
>   https://www.w3.org/Security/wiki/IG/a_view_on_SOP
> This weekend I re-arranged the wiki into three pieces
> 1. Conceptual map : just to give an idea how work from privacy, identity,
> security, logic, and other areas bear on the issue. There are still pieces
> to be filled out here.
> 2. Exceptions to SOP:
>   the more I look around the more I have found well documented and
> justified
> exceptions to narrow understandings of SOP. This should give us some good
> raw
> material for a later exploration of a theory of SOP.
> 3. Implications for Future standards.
>   A third section on who SOP is bringing up issues for future requirements
> such as
> WebPayments.
> 4. Theory of SOP
>   Here I think we'll be able to bring together an extended theory of SOP
> that makes sense of the exceptions, whilst showing how these tie into
> other elements of the conceptual spaces. My feeling is that a bit of work
> in some very initial modal logic of belief contexts would help give a
> secure logical foundation.
> I think this is taking shape. Of course there will be errors,
> improvements. It is not
> complete, so feedback is welcome.
> Henry
> ------------------------------
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
Received on Tuesday, 29 September 2015 16:41:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:38 UTC