Re: Content Security Policy and iframe@sandbox

It's worth noting that if you were able to specify a policy you would like
to apply to a frame (if the page is same-origin of course) the
"frame-by-frame" granularity wouldn't be lost.

I don't think an attribute called policy is the best solution, but I think
something in that direction (being able to specify a CSP from an iframe)
would solve that problem.

I get the differences between CSP and iframe@sandbox, but CSP is still
really useful in sandboxing..

I wonder if the OWASP summit was recorded? It would be nice to be able to
include that.

Greetings


-- Eduardo



On Sun, Feb 13, 2011 at 8:37 AM, Adam Barth <w3c@adambarth.com> wrote:

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