Re: Comments on the Content Security Policy specification

Ian Hickson wrote:
>> If a large site such as Twitter were to implement it, 
>> that's millions of users protected that otherwise wouldn't be.
> 
> Assuming they got it right.

If they don't some researcher gets an easy conference talk out of
bypassing the restrictions and poking fun at them, and then it gets
fixed. The sites most likely to use and benefit from CSP are the ones
most likely to be closely watched.

> I think that something like CSP can definitely be useful. I just think it 
> has to be orders of magnitude simpler.

That's what stalled "Content-Restrictions", and nothing simpler came out
of it. As-is, with all its complications, it has gotten favorable
interest from enough of the right people that it's worth continuing the
experiment.

> Here are some suggestions for simplification:
> 
>  * Remove external policy files.

I'd be happy to drop those, personally. Some people have expressed
bandwidth concerns that would be solved by a cacheable policy file.

>  * Combine style-src and font-src

Ian, meet Eric; Eric meet Ian -- you two work it out. If we don't get
agreement I'd tend to go the way that makes it more likely other browser
vendors will adopt the spec.

>  * Drop the "allow" directive, default all the directives to "self"

"allow" is an important simplification. A fairly simple site (but not
single host) could well use a policy like "CSP: allow *.mydomain.com"
wheras with your proposed simplification they would have to enter each
term of each web technology they use just so they can duplicate
"*.mydomain.com".

I strongly encourage sites to use simple "allow <list>" policies, and
only get into the others if they want to disable certain technologies or
specifically make relax the restrictions on something relatively safe
like img-src.

>  * Move "inline" and "eval" keywords from "script-src" to a separate 
>    directive, so that all the -src directives have the same syntax

I've argued that too and I think we agreed, although I don't see that
reflected in the spec or on the talk page.

>> Or should we do nothing and expect site authors to write correct and 
>> safe PHP+HTML+JavaScript as it stands. CSP seems far less complicated 
>> than the things authors already are expected to understand.
> 
> Authors get the things authors already are expected to understand wrong 
> all the time.

Whatever we create those guys are going to get wrong. I'd rather focus
on what features are useful and necessary for the ones who are able to
get it right.

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

Don't know that any CSP formulation would help prevent that. Not even if
we simplified it to the point of uselessness for complex sites.

>>>> We are not creating this tool for naive, untrained people.
>>> Naive, untrained people are who is going to use it.
>> Yes, but we're really trying to protect the millions of users who visit 
>> Google, Yahoo, PayPal, banks, etc, and hopefully those kinds of 
>> high-traffic sites are run by smart people (yes, I am being naive).
> 
> It doesn't matter who you are trying to protect. This _will_ be used by 
> naive, untrained people, and so we have to make sure it works for them.

"If you make something idiot-proof they'll just make a better idiot"
comes to mind. Or perhaps "Build a system that even a fool can use, and
only a fool will want to use it." George Bernard Shaw (Shaw? Really?)

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

Frankly we're going to resolve this as a mental exercise. Feedback from
people trying to use a working X-CSP implementation will be more
valuable than our guesses about how people will use it. That feedback
will go into the non-X- version of the spec.

>> Using a policy file and having a different one for every page would be 
>> horrid, but what would be the problem with having a cachable policy file 
>> per service? Only the user's initial visit would suffer.
> 
> Making the user's initial visit suffer wouldn't be acceptable to Google, 
> for several reasons; first, it seems that far more visits than just the 
> "initial" visit involve cache misses, and second, the first visit is the 
> most important one in terms of having a good (= fast) user experience.

That's good feedback. However, the ability to use a policy file doesn't
mean you'd have to.

>> If a site hosts all its own
>> content then a policy of "X-Content-Security-Policy: allow self" will
>> suffice and will provide all the XSS protection out of the box.
> 
> It will also break inline scripts, analytics, and ads.

Did you miss the "If a site hosts all its own content" part? Frankly
running scripts from a 3rd party ad provider in their domain should be
scaring sites shitless. Not only do they have to get the security of
their own content EXACTLY RIGHT they also have to trust one or more
other parties to do the same thing. Parties who don't necessarily care
about the site's content or security except to the extent breaches would
lose them business.

> If you design it with the model 
> above, you could introduce the feature as the following instead:
> 
>    script-src: inline only head;
> 
> Legacy UAs would see just "inline", new UAs would see both.

Thanks for that explanation and example.

-Dan

Received on Thursday, 30 July 2009 17:52:28 UTC