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

Re: Sub-origins

From: Brad Hill <hillbrad@gmail.com>
Date: Thu, 29 Aug 2013 14:41:09 -0700
Message-ID: <CAEeYn8hiEh5rBXPusAtcA2dUFd6tmy5RtHuxQ0n+B8uHz6=iNQ@mail.gmail.com>
To: Joel Weinberger <jww@chromium.org>
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>
If the goal of suborigins is to be able to drop privileges for a (less
important) application hosted at an origin, then it's not a good thing if
that app can re-privilege itself by routing through other channels.  So I
see this kind of "incompatibility" as a good thing.  Browsers that don't
know about suborigin sandboxing still work, and "fail open", but once your
browser knows about suborigins, it propagates that knowledge to other
components in a way that causes them to "fail closed".

If you either don't propagate the suborigin, or do it in a way that
requires reworking of basic APIs and IPC to use a potentially incompatible
multi-value structure, I worry it will never really be effective - we'll be
hunting down bypasses for the next decade.

On Thu, Aug 29, 2013 at 2:26 PM, Joel Weinberger <jww@chromium.org> wrote:

> 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:41:38 UTC

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