Re: Comments on the Content Security Policy specification

On Thu, 30 Jul 2009, Gervase Markham wrote:
> 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.

Complexity affects everyone, not just those who use it.


> >   * 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.

I think in almost all cases, multiple headers will be a sign of an attack 
or error, not the sign of cooperation.


> >   * 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".

I think simplification is a win here, even if it makes the language less 
expressive. Obviously, it's a judgement call. I'm just letting you know 
what I think is needed to make this good.


> > 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.

It's dramatically reduced if the format fails safe and is of minimal 
expressiveness.


> > > 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?

Copy-and-paste from sites that didn't understand the spec, for example 
copying from w3schools.com, and then modifying it more or less at random. 
Or copy-and-paste from some other site, without understanding what they're 
doing.


> 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?

Ruby on Rails isn't purporting to be a standard.


> > 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?

I think the dramatic simplification I described would be a good start. I'd 
have to look at the result before I could really say what else could be 
done to make the language safer for novices.


On Thu, 30 Jul 2009, Daniel Veditz wrote:
> > 
> >  * Drop the "allow" directive, default all the directives to "self"
> 
> "allow" is an important simplification.

I don't think that making policies shorter is the same as simplification. 
In fact, when it comes to security policies, I think simplicity 
corresponds almost directly to how explicit the language is. Any 
implications can end up tripping up authors, IMHO.


> > We could remove many of the directives, for example. That would make 
> > it much shorter.
> 
> Make what shorter? The spec, certainly, but probably not the typical 
> policy. And if a complex policy needed those directives then eliminating 
> them hasn't really helped.

Making the spec shorter is a pretty important part of simplifying the 
language. The simpler the spec, the more people will be able to understand 
it, the fewer mistakes will occur.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 11 August 2009 23:17:41 UTC