Re: Sub-origins

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
>>>
>>
>>