Re: Isolated Origins

Thanks for the comments, Charlie.

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

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

Ah, yes, I think you had warned me about this problem a while ago but it
slipped my mind; sorry about that. Mike started a separate thread about
this ("Breaking the `opener` relationship": https://lists.w
3.org/Archives/Public/public-webappsec/2017Apr/0071.html). Does that
variant -- nuking specific properties of cross-orign windows like
`window.postMessage` or `window.frames` -- strike you as more implementable?


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

Hmm. Artur, do you have any thoughts on this in terms of real-world attack
vectors?

This also leads me to wonder whether isolated origins should get a strict
referrer policy applied by default. (If so, and if
https://github.com/whatwg/html/issues/1918 settles on redacting
ancestorOrigins based on referrer, then we might not need to worry about
ancestorOrigins specifically.)


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

Thanks, fixed both.


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

Yeah, this issue has been floating around (also see
https://github.com/WICG/isolation/issues/6) and I also don't have any great
ideas. As you said, it's not specific to expiration times; regardless of
how an origin opts in or out of isolation, there will inevitably be the
possibility of two "same-origin" frames that are in fact not same-origin
because the origin turned on isolation after the other loaded.

Force-reload doesn't seem terrible. There's some precedent for that in
Clear-Site-Data:
https://w3c.github.io/webappsec-clear-site-data/#grammardef-executioncontexts

I also wonder how terrible it would be to not worry about this and say that
it's out of scope to recover from an attack that occurred prior to turning
on isolation. Of course that diminishes the value of Isolate-Me
significantly.


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