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

Re: Content Security Policy and iframe@sandbox

From: Brandon Sterne <bsterne@mozilla.com>
Date: Mon, 14 Feb 2011 17:15:45 -0800
Message-ID: <4D59D3C1.3080603@mozilla.com>
To: Adam Barth <w3c@adambarth.com>
CC: sird@rckc.at, public-web-security@w3.org
On 02/12/2011 11:25 AM, Adam Barth wrote:
> 2) It's unclear whether CSP actually stops all script execution in a frame.
> 
> Point (2) is somewhat subtle.  Consider the case of a targeted
> hyperlink with a JavaScript URL:
> 
> <a href="javascript:alert('greetz')" target="theBestFrame">Click me!</a>
> 
> Which CSP policy controls whether the JavaScript URL executes?  The
> policy of the document that contains the hyperlink or the policy of
> the document contained in theBestFrame?

I would argue that the policy of the container document should get first
priority and then go inward from there.  If inline script is permitted
in the outer document, and the outer document has script access to
theBestFrame, then the javascript: URL would run.  At this point, you
would want to check that theBestFrame's document doesn't have a CSP that
prevents the script from executing.  This would include any policy that
hasn't turned off inline-script restrictions (e.g.
disable-xss-protection).  If there was not such a policy, then you could
run the javascript: URL, but if it made some DOM changes that violated
theBestFrame's CSP, e.g. content-loading restrictions, those would be
prevented.

One design principle we might want to consider is "take the most
restrictive action given a set of conflicting directives".  In other
words, an action should only be permitted if it is allowed by ALL of the
policies in effect.

> Similarly, does CSP prevent a
> plugin from causing script to execute in the context of a document
> (e.g., via NPN_Evaluate)?

It does not in either the Mozilla proposal or our Firefox 4
implementation.  We considered pursuing such a model, but ultimately
decided that it was easier to understand a model that provides
restrictions on the sources of active content but doesn't change the
execution model of such content once it's loaded.

Under the current proposal, sites will need to specify both script-src
and object-src in order to fully mitigate code injection.  We can decide
if it's an improvement to:
1. replace script-src and object-src with code-src (or similar)
2. leave script-src and object-src as is but add code-src as a third
   tier of directive that overrides script-src and object-src
3. leave as is and require sites to write "complete" policies

> Relatedly, you can't write a CSP policy that blocks all plugins.
> Specifically, consider the Gears plugin, which never loads anything
> from a URL.  Even if you have object-src none, the Gears plugin will
> still run because it doesn't violate the policy.  However, with
> @sandbox, the gears plugin will not run.

This specific example worries me a bit.  Have you tested Minefield with
a page that uses Gears and a object-src 'none' policy?  I can dig in a
little more and do some testing if you haven't, but it seems like CSP
should be able to account for this case, even if it currently can't.
Just because a plugin doesn't get loaded via a URL, I don't think it
should get to load under a policy of object-src 'none'.  Perhaps in
cases where there is no URL we should treat the host as 'self'?

> In summary, @sandbox disable scripts and plugins at a semantic layer,
> whereas CSP block various syntactic ways of executing script or
> loading plugins.  That's not to say that one is better or worse than
> the other.  They're just different because they have different goals.

I agree.  I'm not yet convinced (though I still could be) that trying to
combine the two is a good idea.

-Brandon
Received on Tuesday, 15 February 2011 01:15:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 15 February 2011 01:15:45 GMT