Re: Content Security Policy and iframe@sandbox

On Sat, Feb 12, 2011 at 12:49 PM, Steingruebl, Andy
<asteingruebl@paypal-inc.com> wrote:
>> -----Original Message-----
>> From: public-web-security-request@w3.org [mailto:public-web-security-
>> request@w3.org] On Behalf Of Adam Barth
>>
>> @sandbox and CSP are very different.  The primary difference is who choses
>> the policy.  In the case of @sandbox, the embedder chooses the policy.  In
>> CSP, the provider of the resource chooses the policy.
>
> While this is true today, I could imagine a tweak to CSP wherein CSP would control all contents hierarchically.  I already spoke to Brandon about it, but it was just a quick brainstorm.
>
> You could imagine revoking permissions in the frame hierarchy and not granting them back.  This does start to get awfully ugly, but just as CSP controls loading policy for itself, it could also control loading policy for children, right?
>
> Fundamentally, since the existing security model doesn't really provide for strict separation of parent/child (popups, 401's, top-nav) CSP and iframe sandbox both try to control the behavior of resources we pull from other parties.
>
> Do we think that these are both special cases of a general security policy (my intuition says yes) or that they have some quite orthogonal types of security controls that cannot be mixed into a single policy declaration?
>
> One clear problem that comes to mind is that there are policies that come from the "child" such as X-Frame-Options that must break the ordinary parent/child relationship from a precedence standpoint.

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.

Adam

Received on Saturday, 12 February 2011 21:13:21 UTC