Re: Isolated Origins

A few other general questions from reading the current spec:

1) In Section 1.2, how do you plan to implement #2 (cross-origin iframes
inside isolated.com can't access their ancestors)?  I don't know of an
existing mechanism for achieving that.  5.1.4 talks about window.top and
window.parent, but those aren't the only ways to get to those frames-- you
could also use frame names to find them (e.g., with window.open), and I
wouldn't be surprised if there are more ways.

There's also location.ancestorOrigins, which doesn't give you a reference
to the ancestors but does tell you what their origins are.  Is that a
concern?

2) In Section 1.2, should #6 have a mention of putting cross-origin iframes
inside isolated.com into a separate process from isolated.com as well, at
least if possible?   I know this is harder to do in other browsers, but it
does seem like there is a UXSS risk to it when it loads cross-origin
iframes if they stay in its process.

(Also nit: s/example.com/very-important.com/ in the text of #6.)

3) In Section 2 / Issue 4, you introduce the notion of an expiration time.
This, plus the fact that the origin might not start opting into isolation
until the user already has some tabs open to that origin, poses some
challenges for an origin existing in multiple states in the browser at the
same time.  You could even have two tabs with references to each other,
which look same origin but one is considered isolated and the other isn't
(as noted in 5.1.1, I guess).  This seems like it could interact poorly
with existing origin checks in the browser, which might pass if they don't
check the "isolated" getter.  Is there anything we can do to make these
states less error-prone?

For example, we could force-reload all pages from an origin when it becomes
isolated, and leave the isolation in place until the browser exits, even if
it expires.  That would be a way to default to more secure behavior, though
it poses some risk of data loss from the force-reload.  I don't have a
great solution here, but I'm curious for your thoughts.

Charlie



On Wed, Apr 26, 2017 at 3:13 PM, Charlie Reis <creis@google.com> wrote:

>
>
> On Wed, Apr 26, 2017 at 10:31 AM, David Ross <drx@google.com> wrote:
>
>> If yes, it's probably not too bad, but I'm worried that bugs in the
>>> isolated origin would still be damaging even in the double-keyed world. For
>>> example, let's say isolated.com has an XSS which is normally not
>>> exploitable because of isolation; if the origin is reachable when iframed
>>> under foo.com then the XSS still executes under isolated.com and can
>>> send messages as that origin (perhaps safe.non-isolated.com trusts
>>> messages from isolated.com), show prompts with the browser UI
>>> displaying "isolated.com" as the origin, etc. It seems like it might be
>>> preferable not to have to worry about this class of problems.
>>
>>
>> +1  It's going to be hard enough to defend attacks from evil.com -->
>> isolated.com.  It will be even harder to defend against attacks that
>> involve the non-isolated version of the origin as well as the isolated
>> version.
>>
>> An admin interface or a banking UI would be the typical use case for
>> isolated origins.  The choice to use an isolated origin would be driven by
>> a desire to avoid XSS and XSRF that are otherwise pervasive issues on the
>> web, but with more severe consequences for admins / banking users in
>> particular.  I think these users would be just as concerned with
>> clickjacking.  Maybe it would make sense to do two things:
>>
>>    - In isolated origins, change the X-Frame-Options / frame-ancestors
>>    default behavior to disable framing by default.  HTTP responses from an
>>    isolated origin would still be able to opt-in to framing using X-F-O /
>>    frame-ancestors.
>>    - Once an origin is isolated, always present the isolated version of
>>    the origin the user.  Even in framing scenarios.
>>
>> This approach would avoid the problem Artur pointed out, but also provide
>> enough flexibility to an isolated origin so they can support specific usage
>> scenarios requiring frame-ability.
>>
>>
> Hmm, I don't think we can support having subframes in a different
> StoragePartition than their parent page.  That's hard to implement and hard
> to reason about.
>
> I would strongly prefer to prevent iframing isolated sites if we can.
> While Alex is right that you could treat the iframed version as a different
> origin with a different StoragePartition than when loading it in the main
> frame (which is what we did in the old isolated sites
> <http://www.chromium.org/developers/design-documents/isolated-sites>
> project), it made things confusing and potentially harder to secure, as
> Artur noted.
>
>
>>
>> On Wed, Apr 26, 2017 at 5:28 AM, Artur Janc <aaj@google.com> wrote:
>>
>>> On Wed, Apr 26, 2017 at 4:07 AM, Emily Stark <estark@google.com> wrote:
>>>
>>>> On Tue, Apr 25, 2017 at 3:27 PM, Alex Russell <slightlyoff@google.com>
>>>> wrote:
>>>>
>>>>> A few questions:
>>>>>
>>>>>    - The note about needing to process Isolation before cookies is
>>>>>    interesting. Does it mean that this won't be possible to do from a <meta>
>>>>>    tag equivalent?
>>>>>
>>>>> Quite possibly, yeah. I unfortunately don't see how we can make this
>>>> play nicely with meta tags; if the page sets cookies before it goes into
>>>> isolated mode, those cookies won't be accessible.
>>>>
>>>
>>> +1, I'd rather not attempt to make isolated origins work with <meta>
>>> because it seems like a can of worms. One of the ideas that appeals to me
>>> is to consider the isolation bit conceptually similar to HSTS where
>>> isolation would be a property of the entire origin, in which case setting
>>> it from <meta> would likely not fit that model.
>>>
>>> For something like isolated origins I'd expect that the concern about
>>> the difficulty of setting response headers compared to <meta> wouldn't be a
>>> big concern because it's meant for the most highly sensitive applications
>>> where developers need to be able to set headers anyway to control other
>>> security features.
>>>
>>
> Agreed-- it should be origin wide and not settable via <meta>, in order
> for Chrome's process model to know which process and StoragePartition to
> use before the page is committed.
>
> Charlie
>
>
>>
>>>
>>>>
>>>>>    - What's the issue with isolation and iframing? I'd have thought
>>>>>    that one of the valuable aspects of double-keying is protection from
>>>>>    iframing. That is, you can run your main service as isolated and if anyone
>>>>>    iframes you, the isolation won't be invoked (you'll be in the main storage
>>>>>    container) and therefore that "version" simply won't have ambient authority.
>>>>>
>>>>> Hmm, this could probably be made to work. One concern I have is
>>>> whether it makes double-keying not enough and we actually need to key by
>>>> the whole frame tree. If isolated1.com frames isolated2.com which
>>>> makes a cross-origin request to blah.com, do the cookies for blah.com
>>>> need to be triple-keyed? I think they might need to be to be consistent
>>>> with the threat model.
>>>>
>>>> (Also, this makes me realize that we didn't write anything in the spec
>>>> about double-keying storage other than cookies; that needs to be addressed.
>>>> Oops.)
>>>>
>>>
>>> Does double-keying storage imply considering [isolated.com] and [
>>> isolated.com iframed by foo.com] to be separate origins, i.e. not being
>>> able to have direct DOM access to each other?
>>>
>>> If yes, it's probably not too bad, but I'm worried that bugs in the
>>> isolated origin would still be damaging even in the double-keyed world. For
>>> example, let's say isolated.com has an XSS which is normally not
>>> exploitable because of isolation; if the origin is reachable when iframed
>>> under foo.com then the XSS still executes under isolated.com and can
>>> send messages as that origin (perhaps safe.non-isolated.com trusts
>>> messages from isolated.com), show prompts with the browser UI
>>> displaying "isolated.com" as the origin, etc. It seems like it might be
>>> preferable not to have to worry about this class of problems.
>>>
>>>
>>>>
>>>>>    - I'd love a solution to opener disownership that's generic.
>>>>>
>>>>> Can you clarify this? I don't understand.
>>>>
>>>
>>> Alex, the CSP3 draft has https://w3c.github.io/webappse
>>> c-csp/#directive-disown-opener which might be what you're looking for?
>>> FWIW I'd agree with the note in the spec and this bug
>>> <https://github.com/w3c/webappsec-csp/issues/194> that this needs some
>>> more deliberation.
>>>
>>>
>>>>
>>>>>    - I'm not sure I understand the serviceworker integration points.
>>>>>    If the behavior of isolation is double-keying when isolated, doesn't this
>>>>>    just imply that these are parallel (separate) SW registrations?
>>>>>
>>>>> I don't think I understand this question either. The point of the SW
>>>> integration is that a SW from the isolated origin must explicitly allow
>>>> navigations to the isolated origin, and they'll fail otherwise. Does that
>>>> clarify it at all?
>>>>
>>>>
>>>>> Thanks!
>>>>>
>>>>> On Tuesday, April 25, 2017, Emily Stark <estark@google.com> wrote:
>>>>>
>>>>>> On the last call, I mentioned that I would send out an "Isolate-Me"
>>>>>> draft. This is a proposal for a mechanism by which an origin can opt in to
>>>>>> isolate itself from other web content -- probably most useful for
>>>>>> high-value security-critical applications that are willing to give up some
>>>>>> functionality for such isolation.
>>>>>>
>>>>>> Please take a look at this faint ghost of a spec that aims to explain
>>>>>> the threat model more and nail down what these isolation mechanisms are:
>>>>>> https://wicg.github.io/isolation/index.html
>>>>>>
>>>>>> Any comments or feedback, either here or in the GitHub repo, would be
>>>>>> very welcome.
>>>>>>
>>>>>> David Ross (cc'ed) might also want to share some thinking he's done
>>>>>> about alternative shapes for the part of the proposal that deals with
>>>>>> navigation restrictions.
>>>>>>
>>>>>> Thanks!
>>>>>> Emily
>>>>>>
>>>>>
>>>>
>>>
>>
>