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.


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

This is great. We should do this.

dev-security mailing list

Reply via email to