Re: Comments on the Content Security Policy specification

On Thu, 16 Jul 2009, Daniel Veditz wrote:
> Ian Hickson wrote:
> > 
> > * The more complicated something is, the more mistakes people will 
> > make.
> 
> We encourage people to use the simplest policy possible. The additional 
> options are there for the edge cases.

It doesn't matter what we encourage. Most authors are going to be using 
this through copy-and-paste from tutorials that were written by people who 
made up anything they didn't work out from trial and error themselves.


> > I believe that if one were to take a typical Web developer, show him 
> > this:
> > 
> >    X-Content-Security-Policy: allow self; img-src *;
> >                               object-src media1.com media2.com;
> >                               script-src trustedscripts.example.com
> > 
> > ...and ask him "does this enable or disable data: URLs in <embed>" or 
> > "would an onclick='' handler work with this policy" or "are framesets 
> > enabled or disabled by this set of directives", the odds of them 
> > getting the answers right are about 50:50.
> 
> Sure, if you confuse them first by asking about "disabling". 
> _everything_ is disabled; the default policy is "allow none". If you ask 
> "What does this policy enable?" the answers are easier.

I was trying to make the questions neutral ("enable or disable"). The 
authors, though, aren't going to actually ask these questions explicitly, 
they'll just subconsciously form decisions about what the answers are 
without really knowing that's what they're doing.


> data URLs? nope, not mentioned
> inline handlers? nope, not mentioned

How is an author supposed to know that anything not mentioned won't work?

And is that really true?

   X-Content-Security-Policy: allow *; img-src self;

Are cross-origin scripts enabled? They're not mentioned, so the answer 
must be no, right?

This isn't intended to be a "gotcha" question. My point is just that CSP 
is too complicated, too powerful, to be understood by many authors on the 
Web, and that because this is a security technology, this will directly 
lead to security bugs on sites (and worse, on sites that think they are 
safe because they are using a Security Policy).


> >    X-Content-Security-Policy: allow https://self:443
> 
> Using "self" for anything other than a keyword is a botch and I will 
> continue to argue against it. If you mean "myhost at some other scheme" 
> then it's not too much to ask you to spell it out. I kind of liked 
> Gerv's suggestion to syntactically distinguish keywords from host names, 
> too.

The examples I gave in the previous e-mail were all directly from the 
spec itself.


> > ...I don't think a random Web developer would be able to correctly 
> > guess whether or not inline scripts on the page would work, or whether 
> > Google Analytics would be disabled or not.
> 
> Are inline scripts mentioned in that policy? Is Google Analytics? No, so 
> they are disabled.

_I_ know the answer. I read the spec. My point is that it isn't intuitive 
and that authors _will_ guess wrong.


> I'll admit that the default "no inline" behavior is not at all obvious 
> and people will just have to learn that

This strategy has not worked in the past.


> We are not creating this tool for naive, untrained people.

Naive, untrained people are who is going to use it.


> Taking that approach to any security technology is going to get you into 
> trouble.

Have you seen the Web? :-)

I agree entirely. But we don't get to require that people pass a test 
before they use a technology. They'll use it because they heard of it on 
w3schools, or because someone on digg linked to it, or because their 
friend at the local gym heard his sysadmin team is using it.

We know that people do this. We have to take that into account.


> > This would then likely make them _less_ paranoid about XSS problems,
> 
> I hope not, since it does nothing to help their visitors using legacy 
> browsers that don't support CSP.

That's a temporary situation. In 20 years, when everyone supports it and 
nobody cares about today's browsers, CSP will make people less paranoid.


> CSP is a back-up insurance policy, defense-in-depth and not the defense 
> itself.

Again, you and I know that. The people using it won't.


> > I'm concerned about the round-trip latency of fetching an external 
> > policy
> 
> Us too. We don't like the complexity added by the external policy file, 
> but it was a popular request. It could reduce bandwidth for a site with 
> a complex policy since it would be cachable.

I would recommend making the entire policy language signficantly simpler, 
such that it can be expressed in less space than a URL's length, which 
would solve this problem as well as the above issues.


> > or would it block page loading?
> 
> It will block page _parsing_, just as a <script> tag must (except, of 
> course, before parsing starts).

I think that would basically make the external policy unusable for Google 
properties. Specifying a policy inline would still be ok though.


> We're seriously considering dropping <meta> support.

I would support dropping <meta> support.


> > I don't think UAs should advertise support for this feature in their 
> > HTTP requests. Doing this for each feature doesn't scale.
> 
> I personally agree for all the reasons you mention, but we still have a 
> potential versioning problem to resolve. Or not -- if we do nothing we 
> could always add a CSP-2 header in the future if necessary. I'm just 
> worried that it's unlikely that we thought of everything the first time 
> through.

Just make sure it's forwards-compatible, so you can add new features, 
then you don't need to version it. (The same way HTML and CSS and the DOM 
have been designed, for instance.)

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

Received on Friday, 17 July 2009 03:17:58 UTC