Re: Comments on the Content Security Policy specification

On 29/07/09 23:23, Ian Hickson wrote:
>   * Remove external policy files.

I'm not sure how that's a significant simplification; the syntax is 
exactly the same just with an extra level of indirection, and if that 
makes things too complicated for you, don't use them.

>   * Remove<meta>  policies.

Done.

>   * If there are multiple headers, fail to fully closed.

How is this a simplification? It means that if there are multiple people 
(e.g. an ISP and their customer) who want input into the policy, the ISP 
or the customer has to manually merge and intersect the policies to make 
one header, rather than the browser doing it. In other words, the 
intersection code gets written 1000 times, often badly, rather than 
once, hopefully right.

>   * Combine img-src, media-src, object-src, frame-src

But then the combined lotsofthings-src would have to be set to the 
intersection of all the above, which means e.g. far more potential 
sources of objects (in particular) than you might otherwise want. 
"object-src: none" sounds to me like a great idea for a load of sites 
which also want to display images.

OTOH, "lotsofthings-src: host1.com host2.com host3.com" would still be a 
big improvement over now, where we effectively have "lotsofthings-src: all".

>   * Combine style-src and font-src

That makes sense.

>   * Drop the "allow" directive, default all the directives to "self"

That's an interesting idea.

>   * Move "inline" and "eval" keywords from "script-src" to a separate
>     directive, so that all the -src directives have the same syntax

Yes, we've done this.

> I'm concerned that people will eventually do something that causes the
> entire policy to be ignored, and not realise it ("yay, I fixed the
> problem") or will do something that other people will then copy and paste
> without understanding ("well this policy worked for that site... yay, now
> I'm secure").

These would be issues with any possible formulation.

>> I imagine sites starting with the simplest policy, e.g. "allow self",
>> and then progressively adding policy as required to let the site
>> function properly.  This will result in more-or-less minimal policies
>> being developed, which is obviously best from a security perspective.
>
> This is maybe how competentely written sites will do it. It's not how most
> sites will do it.

How do you expect them to do it? Start with "allow all"? That's like 
saying "some people will start their Ruby on Rails web application by 
writing it full of XSS holes, and then try and remove them later". This 
may be true, but we don't blame Ruby on Rails. Do we?

> You are assuming the person reading all this is familiar with security
> concepts, with Web technologies, with "whitelists" and wildcards and so
> on. This is a fundamentally flawed assumption.

I don't see how we could change CSP to make it understandable to people 
unfamiliar with Web technologies and wildcards. I think almost everyone 
is familiar with the concept of a whitelist, but perhaps under a 
different name. Any suggestions?

> Seatbelts are simple to understand. Make CSP as simple as seatbelts and
> I'll agree.

Ah, the magic "fix my security problems" header. Why didn't we think of 
implementing that before?

> Make the BNF that defines the syntax be something that matches all
> possible strings.
<snip>

This is great. We should do this.

Gerv

Received on Thursday, 30 July 2009 14:07:31 UTC