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
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
