Re: Content Security Policy and iframe@sandbox

I've added both targeted JavaScript URLs and URL-less plug-ins to the
wiki under the heading "things to worry about."

http://www.w3.org/Security/wiki/Content_Security_Policies#Things_to_Worry_About

I'm not sure what the best thing to do is, but I wanted to record
these thoughts so we don't forget them.

Adam


On Mon, Feb 14, 2011 at 5:15 PM, Brandon Sterne <bsterne@mozilla.com> wrote:
> 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:49:26 UTC