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 13:49:36 -0700
To: Adam Barth <w3c@adambarth.com>, "sird@rckc.at" <sird@rckc.at>
CC: "public-web-security@w3.org" <public-web-security@w3.org>
Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB3A9226EA@DEN-MEXMS-001.corp.ebay.com>
> -----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. 

- Andy
Received on Saturday, 12 February 2011 20:50:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 12 February 2011 20:50:12 GMT