W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2013

Re: Sub-origins

From: Joel Weinberger <jww@chromium.org>
Date: Thu, 29 Aug 2013 14:26:28 -0700
Message-ID: <CAHQV2KnorCNkrFWnzux351QDOw_0fsL9V8eKUHdYikpwn6RO3w@mail.gmail.com>
To: Brad Hill <hillbrad@gmail.com>
Cc: Michal Zalewski <lcamtuf@google.com>, Mike West <mkwst@google.com>, Adam Barth <abarth@google.com>, Daniel Veditz <dveditz@mozilla.com>, Michal Zalewski <lcamtuf@coredump.cx>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Devdatta Akhawe <dev.akhawe@gmail.com>
Just to throw this out there, I believe most of Adam and my objections to
Michal's serialized version of suborigins are around usability. However, I
think we probably alleviate most of that my simply requiring in the spec
that they never appear to a user (that is, a frame URL will always appear
in UI elements without the suborigin).

However, if I'm not mistaken, this brings a whole other set of legacy
problems. Part of the goal of the separate, structured suborigin was that
legacy browsers and servers looking in the traditional origin space would
see a normal origin (in the case of httpheaders) or nothing (in the case
of postMessage). However, in any of these serialized versions, a legacy
application will now see something that's *almost* a normal origin, but not
quite. That seems like a dangerous proposition in it's own right.

Perhaps I'm missing something, though. Brad, is this not a concern of
yours? How would we expect a legacy browser,  for example, to gracefully
handle a hash origin or http://foo$bar.com origin?
On Aug 29, 2013 9:42 AM, "Brad Hill" <hillbrad@gmail.com> wrote:

> I would just caution against being too casual about considering the
> browser the only citizen of the SOP ecosystem, even if you happen to think
> the recent history of such was misguided.
> For an example of a protocol encoding and comparing origins, consider
> "Universal 2nd Factor" (previously known as Gnubby) which Google is leading
> the development of.
> https://docs.google.com/document/d/1Jm_xAJTZGulMOkYOQm-fIQhhkd2VDr9578oh0KOwcEw/edit#heading=h.q5kqrl82hzpj
> And also consider the rich extension ecosystem for Chrome utilizing
> origins for security isolation.
> https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final177_0.pdf
> And the set of cross-origin attacks on mobile platforms recently explored
> by MSR, and their proposed mitigation using an origin indication:
> http://research.microsoft.com/pubs/200406/ccs127-wang.pdf
> I'm interested in exploring a way to encode suborigins as first-class
> citizens of URL space a bit further as an alternative to the hash scheme,
> since the single-value URL is the near-universal means of communicating
> resource information with embedded security boundaries between the various
> pieces of the web ecosystem.
> On Thu, Aug 29, 2013 at 8:53 AM, Michal Zalewski <lcamtuf@coredump.cx>wrote:
>> I am not particularly excited about the hashing proposal. It adds
>> complexity to the scheme that may discourage developers, and I do not see
>> it offering any clear benefits over other possible serializations.
>> For some context, the original proposal we started with relied on
>> encoding the suborigin as a part of a serializable URL; in the original
>> draft, I suggested something like "http://$suborigin.example.com/",
>> where '$' would be any character that is not allowed to organically appear
>> unescaped in the host name part. This greatly simplifies the proposal
>> because it avoids all the concerns about backward compatibility with
>> same-origin checks, CORS headers, postMessage event properties, all sorts
>> of permission prompts, and so on. However, it has the downside of mucking
>> with the URL syntax.
>> One of the counterproposals was the scheme mentioned by Joel,
>> "http+suborigin://example.com/". This approach has a higher likelihood
>> of creating incompatibilities - for eample, a server that only looks at the
>> host name field (but not the protocol) to permit or reject CORS requests,
>> could be in trouble. It also seems like a bad abuse of that part of the URL.
>> Since we expected this to come up in a public discussion anyway, we
>> settled on a clean but not backward-compatible approach of serializing the
>> origin as null in several specific cases, and exposing the suborigin data
>> via a separate channel. I agree that this carries some interesting risks.
>> /mz
Received on Thursday, 29 August 2013 21:26:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:34 UTC