Isolated Origins

# Emily Stark (25 days ago)

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

Contact us to advertise here
# Alex Russell (25 days ago)

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?
  • 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.
  • I'd love a solution to opener disownership that's generic.
  • 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?
# David Ross (25 days ago)

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.

That would be: wicg.github.io/isolation/navmanager.html

However section 5 is now out of date w.r.t. the mechanism described in the primary doc (wicg.github.io/isolation/index.html). The earlier sections of the nav manager doc should still provide some useful / relevant context on the navigation manager concept overall.

I will likely adapt section 5 in my nav manager doc to be consistent with the approach Emily's described in the primary doc.

On Tue, Apr 25, 2017 at 3:27 PM, Alex Russell slightlyoff@google.com

wrote:

# Emily Stark (25 days ago)

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.

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

  • I'd love a solution to opener disownership that's generic.

Can you clarify this? I don't understand.

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

# Artur Janc (24 days ago)

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.

  • 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 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](https://github.com/w3c/webappsec-csp/issues/194) that this needs some more

deliberation.

# David Ross (24 days ago)

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.

# Charlie Reis (24 days ago)

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

# Charlie Reis (24 days ago)

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

# Emily Stark (23 days ago)

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": 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 whatwg/html#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 WICG/isolation#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: 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.

# Artur Janc (22 days ago)

On Fri, Apr 28, 2017 at 7:27 AM, Emily Stark estark@google.com wrote:

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

I can't think of anything interesting an attacker could do with location.ancestorOrigins. In general, I'm also less worried about attacks from iframed content given the amount of control the developer has over the resources they decide to embed; however, if we're concerned about this we could think of requiring cross-origin frames in isolated documents to be sandboxed with some reasonable set of flags.

Want more features?

Request early access to our private beta of readable email premium.