Re: [site-isolation-dev] Only way to prevent top.location changes from iFrame is using sandbox attribute which blocks plugins

[Charlie Reis]

[+securi...@chromium.org, mkwst@, jschuh@; site-isol...@chromium.org to BCC]

Sorry for the late reply.  security-dev@ is a better list for this than site-isolation-dev@, since the latter is about our implementation of http://www.chromium.org/developers/design-documents/site-isolation.

As you mention, sandboxed iframes can't load plugins.  Flash has its own capabilities the browser can't easily restrict, so I don't know of a way to do what you're asking.  The other folks CC'd might know more.

That said, if you're seeing a Chrome crash with that JS code, we'd like to fix it.  Please file a bug with the repro steps at https://crbug.com/new.

Thanks!

Charlie

On Mon, Mar 23, 2015 at 5:44 PM, <faste...@gmail.com> wrote:

Not sure if this is the right mailing list but seems appropriate since it relates to Site Isolation. We'd like to prevent ads from doing top.location = "http://myscammyadsite.com" but a lot of our ads are also still using Flash which means we can't just use the sandbox attribute, since that blocks plugins.

Is there any other way of preventing this? I jokingly tried Object.defineProperty(window, 'location', {configurable: false, editable: false}) but that just crashes the Chrome tab immediately after running. That also wouldn't prevent top.location.replace().

Thanks!
James

[Mike West]

On Wed, Apr 8, 2015 at 6:52 PM, Charlie Reis <cr...@chromium.org> wrote:

[+securi...@chromium.org, mkwst@, jschuh@; site-isol...@chromium.org to BCC]

Sorry for the late reply.  security-dev@ is a better list for this than site-isolation-dev@, since the latter is about our implementation of http://www.chromium.org/developers/design-documents/site-isolation.

As you mention, sandboxed iframes can't load plugins.  Flash has its own capabilities the browser can't easily restrict, so I don't know of a way to do what you're asking.  The other folks CC'd might know more.

Charlie is correct; we don't have a good mechanism other than sandbox which would restrict a frame's ability to bust out of the frame by navigating the top-level browsing context. That said, it's not clear that blocking top-level navigation would really be feasible in the case you're talking about: clicking on the advertisement should take the user somewhere, right?

-mike

[James Hartig]

Thanks for the reply Charlie and apologies for posting to the wrong list.

@Mike, that's true so sandbox would be need to follow the same restrictions as popups, where it would be allowed if it originated from a click event or if the href of the anchor was used. We would just like to explicitly block iframes (read: ads) that on load just run window.top.location = http://myscammyadsite.com/ and immediately redirect the user away to a scam site. However, I don't think it would be terrible if sandboxing just never allowed access to change location from JS but still allowed anchor tags to work.

Sandboxing does what we want but also blocks Flash which unfortunately a decent amount of advertisers still use. Maybe if there was another sandbox option that allowed plugins? Not trying to change the spec since I realize that would take a lot of time and discussion, I was mostly just asking if anyone had any ideas of what we could do (possibly besides sandboxing). If the answer is nothing, that's acceptable.

--
James Hartig
Grooveshark.com

[Brad Hill]

I've heard similar requests for a sandbox that allows plugins from my colleagues. One of the big problems with that approach is that origin-sandboxing is one of the most important and valuable features, but the major plugins (java, flash, sliverlight) all have their own, different versions of what the "same origin policy" is, with special exceptions for downloading new code based on IP or object origin, reading off-origin data based on policy files hosted cross-origin, etc. It's an almost impossible task to reconcile those with a uniform SOP in the browser and propagate the guarantees of origin-sandboxing to plugins.

I think a better approach is to have a CSP directive that restricts where a resource may navigate itself. Deian Stefan plans to propose that (and a postMessage restricting directive) for CSP3 in support of the COWL deliverable we've recently adopted in WebAppSec. It's something I'd like to see, as well. http://www.w3.org/2011/webappsec/

-Brad Hill

[Justin Schuh]

On Thu, Apr 9, 2015 at 10:10 AM, Brad Hill <hill...@gmail.com> wrote:

I've heard similar requests for a sandbox that allows plugins from my colleagues.  One of the big problems with that approach is that origin-sandboxing is one of the most important and valuable features, but the major plugins (java, flash, sliverlight) all have their own, different versions of what the "same origin policy" is, with special exceptions for downloading new code based on IP or object origin, reading off-origin data based on policy files hosted cross-origin, etc. It's an almost impossible task to reconcile those with a uniform SOP in the browser and propagate the guarantees of origin-sandboxing to plugins.

I think a better approach is to have a CSP directive that restricts where a resource may navigate itself.  Deian Stefan plans to propose that (and a postMessage restricting directive) for CSP3 in support of the COWL deliverable we've recently adopted in WebAppSec.  It's something I'd like to see, as well.  http://www.w3.org/2011/webappsec/

Would that also apply to nested browsing contexts navigating top? Because at this point I think it's safe to assume browsers have X-Frame-Options support, which is superior to frame-busting. So, it seems reasonable to give the containing document the ability to block navigation by ancestors given that ancestors already have a means of denying their inclusion.

-Brad Hill

[Brad Hill]

That's definitely one of the complications with attempting confinement we'll have to analyze - but it seems logical that if you were going to forbid a given browsing context from navigating itself except to whitelisted locations as a containment mechanism, you would need to propagate that to child contexts as well as attempts to do parent and popup navigations, or it's an obvious information leak.