W3C home > Mailing lists > Public > public-web-security@w3.org > February 2011

RE: Content Security Policy and iframe@sandbox

From: Steingruebl, Andy <asteingruebl@paypal-inc.com>
Date: Sat, 12 Feb 2011 22:01:49 -0700
To: Adam Barth <w3c@adambarth.com>
CC: "sird@rckc.at" <sird@rckc.at>, "public-web-security@w3.org" <public-web-security@w3.org>
Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB3A92271B@DEN-MEXMS-001.corp.ebay.com>
> -----Original Message-----
> From: Adam Barth [mailto:w3c@adambarth.com]
 
> That all sounds very abstract.  If you have some concrete examples, that
> might be more productive to discuss.  When enforcing policy supplied by one
> origin on another origin, we need to be careful to consider the case where
> the policy providing origin is the attacker and the origin on which the policy is
> being enforced is the victim.

SiteA  wants to make sure it cannot ever be framed.  It deploys X-Frame-Options headers and framebusting JS, and maybe even CSP frame-ancestors.

SiteB wants to make sure it never loads data from anything other than SiteB (no non-origin loads).  It outputs CSP headers to this effect

SiteC wants to make sure that any content it frames cannot run ActiveX controls, nor do a 401 authentication.  It can't really do this with current iframe sandboxing, but pretend it could...

SiteC wants to control the behavior of children that it frames.  It needs to advertise this policy to a web browser.  It has two choices:

1. It can do it inline in the HTML it outputs with extra attributes of the iframe it creates.  SiteC is in complete control of the HTML that creates the iframe.  I can impose any policy via sandbox attributes. Currently for example, it can disable JS in the frame.  If it frames SiteA, SiteA's framebusting JS will never run, but the browser will respect its X-Frame-Options headers.

2. SiteC is also totally in control of all HTTP headers it emits.  It could just as easily indicate policy choices for all frames via CSP.  It could advertise a blanket policy (No JS, No ActiveX).  Advertising a page-specific, or frame/target specific policy is substantially more difficult and probably unwieldy. But, depending on how SiteC is configured, setting a global site policy via headers offers a potential separation of duties that #1 does not, it allows website admin to specific things that each web developer might not be able to.

3. Because all of SiteA,B,C are in different origins, they don't really have to worry about polluting other origins, but they do have to worry about problematic behavior such as top-nav, 401-auth popups, etc.  Parents need to constrain certain behavior of things they embed, according to certain rules of whether the child allows itself to be framed.

I totally get how existing iframe sandboxing that turns off JS is problematic for sites older browsers that don't support X-Frame-Options.  We already have a complicated interaction between these multiple security controls.  

Can you give me an example of why my #1/#2 are actually that different?  Whether we control behavior with headers of inline content, each site is totally responsible for what it emits, and can already control in some interesting ways the behavior of content it frames/includes.

- Andy
Received on Sunday, 13 February 2011 05:02:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 13 February 2011 05:02:28 GMT