Comments on the Content Security Policy specification

First, let me state up front some assumptions I'm making:

* Authors will rely on technologies that they perceive are solving their 
  problems,

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

* The more complicated something is, the more mistakes people will make.


I think CSP is orders of magnitude too complicated to be a successful 
security mechanism on the Web.

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.

Similarly, given the following:

   X-Content-Security-Policy: allow https://self:443

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

I think that this complexity, combined with the tendency for authors to 
rely on features they think are solvign their problems, would actually 
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. This would then likely make them _less_ 
paranoid about XSS problems, which would further increase the possibility 
of them being attacked, with a good chance of the policy not actually 
being effective.



Other comments:

I'm concerned about the round-trip latency of fetching an external policy 
file. Would the policy only be enforced after it is downloaded, or would 
it block page loading? The former seems like a big security problem (you 
would be vulnerable to an XSS if the attacker can DOS the connection). The 
latter would be unacceptable from a performance perspective. Applying a 
lockdown policy in the meantime would likely break the page (e.g. no 
scripts or images could be fetched).

I think CSP should be more consistent about what happens with multiple 
policies. Right now, two headers will mean the second is ignored, and two 
<meta>s will mean the second is ignored; but a header and a <meta> will 
cause the intersection to be used. Similarly, a header with both a policy 
and a URL will cause the most restrictive mode to be used (and both 
policies to be ignored), but a misplaced <meta> will cause no CSP to be 
applied.

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.

I don't think UAs should advertise support for this feature in their HTTP 
requests. Doing this for each feature doesn't scale. Also, browsers are 
notoriously bad at claiming support accurately; since bugs will be present 
whatever happens, servers are likely to need to do regular browser 
sniffing anyway, even if support _is_ advertised. On the long term, all 
browsers would support this, and during the transition period, browser 
sniffing would be fine. (If we do add the advertisment, we can never 
remove it, even if all browsers support it -- just like we can't remove 
the "Mozilla/4.0" part of every browser's UA string now.)

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

Received on Thursday, 16 July 2009 10:51:40 UTC