Re: [Content Security Policy] Proposal to move the debate forward

On 27/01/11 20:39, Adam Barth wrote:
> Is there some reason we need to synchronize on a "version 1" feature
> set?  I'd prefer an extensible model more like HTML where we can each
> implement different parts of CSP on different schedules.  For example,
> something more in the spirit of
> <http://blog.whatwg.org/html-is-the-new-html5>.

I don't think anyone can stop you from implementing what you want to 
implement on your own schedule :-) On the other hand, if all the 
browsers implement different initial subsets of CSP, that's not 
particularly helpful for site authors. If a discussion of what the 
initial feature set is gives each browser maker some idea of what the 
others are likely to implement, and also exposes decision makers to the 
arguments in support of each feature, that will be a win.

>> 2. Content restrictions
>>    a. allow: catch-all for content-types not specified in policy
>>    b. img-src: domains permitted to load images
>>    c. media-src: domains permitted to load<video>,<audio>
>>    d. object-src: domains permitted to load plugin content
>>    e. frame-src: domains permitted to be loaded in<iframe>s
>>    f. font-src: domains permitted to load fonts
>>    g. xhr-src: domains permitted to send XHR to
>>    h. style-src: domains permitted to load stylesheets
>
> I'm not that excited about these features.  Maybe I don't understand
> the use cases sufficiently, but the benefits from these features seem
> outweighed by their complexity.

The general use case for this type of restriction is: I want to restrict 
the sites which can load content, so a content injection can't pull in 
arbitrary content from evil.com. You could argue that all we need for 
this really is the "allow" directive. The further use case for the 
subdivisions is that it should be possible to trust some sites for some 
things (e.g. YouTube for video) without trusting them for everything.

> For example, what is the use case for
> being able to restrict font-src?

Typekit or Google Fonts. I can certainly imagine wanting to do:

allow: 'self'; font-src: fonts.typekit.com

without allowing typekit to provide any other sort of content.

Or, to think about it another way: if I only have "allow", and want to 
allow images from www.somewhere.com, I have to be pretty confident about 
the security of www.somewhere.com and the fact that they won't get 
broken into so someone can upload a dodgy script and then use an XSS 
hole in my code to compromise my users. If I have img-src, I don't need 
to have any reassurance about their security, because all they can send 
me are images.

> Here is a use case that seem related to the above that might be worth
> thinking about:
>
> 1) My site is entirely served over HTTPS, but my developers keep
> including mixed content by mistake.  I wish I could set a policy for
> my site that prevented me accidentally loading insecure content.
>
> Maybe there are other good use cases for this feature that I don't understand?

This use case was considered for CSP.

X-Content-Security-Policy: allow https://*:443

https://wiki.mozilla.org/Security/CSP/Specification#Sample_Policy_Definitions 
, example 4.

>> 4. Clickjacking protection
>>    a. frame-ancestors: list of domains permitted to embed the resource
>>       in an iframe
>
> IMHO, clickjacking is a quagmire.  I'd love to see a solution, but I'm
> not really convinced that this is it.  I'd like to avoid being drawn
> into yet another discussion on this topic, if at all possible.

What is incorrect about the following sequence of logic?

1) Most sites don't use frames.
2) All those sites don't need to be framed to work properly.
3) All those sites could therefore use frame-ancestors: none.
4) frame-ancestors: none entirely defeats clickjacking.
5) The CSP frame-ancestors mechanism provides a total solution to
    clickjacking for most sites in a single statement.

>> 5. Options (mechanisms to change default CSP behaviors)
>>    a. inline-script: permit inline script to execute
>>    b. eval-script: permit eval() and related functions to be used
>
> If we manage to disentangle (1) from the rest of these features, then
> we probably don't need (a).

Why is the necessity or not of (a) dependent on whether we implement 
"the rest of these features"?

> Enabling inline-script defeats the script
> controls, so the way folks should "enable" inline script is by not
> using the script controls.

Not if we support script-nonce. One can easily imagine people using 
inline-script and script-nonce together.

> Obviously we need a policy delivery mechanism.  I suspect there are
> strong use cases for both (a) and (b).  The previous CSP proposal has
> a complex mechanism for merging policies.  IMHO, we should go with the
> much simpler "first one wins" strategy.  Headers trump<meta>  tags.
> Textually earlier headers trump textually later headers.

The use case for the more complex policy was that sites may want a 
certain site-default policy, but be allowed to tighten it for particular 
pages.

Or, to put it another way: if a site already has a CSP policy, "first 
one wins" means that page authors with no access to headers cannot set a 
more strict policy even if they want to.

OTOH, if that doesn't convince us. "first one wins" could be 
backwardly-compatibly extended to "each subsequent one only tightens" if 
later on people give us more compelling reasons.

Gerv

Received on Friday, 28 January 2011 10:27:09 UTC