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. `._.-(,_..'--(,_..'`-.;.'
___
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.
