Re: Comments on the Content Security Policy specification

Ian Hickson wrote:
> * Authors will rely on technologies that they perceive are solving their 
>   problems,

XSS is a huge and persistent problem on the web. If this solves that
problem authors will use it.

> * Authors will invariably make mistakes, primarily mistakes of omission,

CSP is designed so that mistakes of omission tend to break the site
break. This won't introduce subtle bugs, rudimentary content testing
will quickly reveal problems.

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

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

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

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

> ...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'll admit that the default "no inline" behavior is
not at all obvious and people will just have to learn that, but when it
comes to domains it should be pretty clear from the syntax that anything
not explicitly "allowed" is, in fact, not allowed.

> lead to authors writing policy files in what would externally appear to be 
> a random fashion, changing them until their sites worked, and would then 
> assume their site is safe.

We are not creating this tool for naive, untrained people. We don't
expect every site to use it. Taking that approach to any security
technology is going to get you into trouble.

> 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. CSP is a back-up insurance policy,
defense-in-depth and not the defense itself.

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

> or would it block page loading?

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

> would be unacceptable from a performance perspective.

No more than a <script> tag I would think. And anyway, if it's a
performance problem for any given site then they can always go the
preferred route of putting the policy in the header.

> should be more consistent about what happens with multiple policies.

Yup, this is a muddled area that needs more work.

> A policy-uri to a third-party domain is blocked supposedly to prevent an 
> XSS from being able to run a separate policy, but then the policy can be 
> inclued inline, so that particular hole doesn't seem to be actually 
> blocked.

We're seriously considering dropping <meta> support. We added it
worrying about hosting services that don't give authors the ability to
set HTTP headers, but such sites aren't likely to have anything worth
stealing. Any server scripting environment that supports back-end data
should have the ability to set headers. Dropping <meta> support
simplifies things greatly, although it may leave some web authors out in
the cold.

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

-Dan Veditz

Received on Friday, 17 July 2009 01:43:24 UTC