Re: Content Security Policy and iframe@sandbox

On Sat, Feb 12, 2011 at 9:01 PM, Steingruebl, Andy
<asteingruebl@paypal-inc.com> wrote:
>> -----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.

In this example, the trade-off for Site C seems to boil down to the
granularity of the policy.  Using attributes on a frame is more
fine-grained because Site C can make these decisions on an
iframe-by-iframe basis whereas using a document-wide policy is more
coarse-grained.

Of course, there's a trade-off between different granularities.  On
the one hand, fine-grained gives the site more control over how
different iframes behavior.  On the other hand, it's much easier to
audit and understand the effects of a coarse-grained policy.

Adam

Received on Sunday, 13 February 2011 07:38:48 UTC