- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Fri, 17 Jul 2009 09:24:44 -0700
- To: Ian Hickson <ian@hixie.ch>
- CC: Brandon Sterne <bsterne@mozilla.com>, Sid Stamm <sid@mozilla.com>, www-archive@w3.org, jonas@sicking.cc, dev-security@lists.mozilla.org
Ian Hickson wrote: > 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). So do you have a simpler syntax to suggest? A different approach entirely? 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. >>> 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. > > The examples I gave in the previous e-mail were all directly from the > spec itself. The spec is a group effort and I'm sure there are things in it each of us would prefer to be different. It's also not set in stone, which is why I mention things like this (but I don't hear a lot of agreement so maybe everyone else likes using "self" as a pseudo-host). >> 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. But in this case they will learn rather quickly if their site doesn't work. >> 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). > 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. I don't know what to do with this feedback. Are you saying "don't do CSP"? Do you have suggestions on how to make it safer or simpler to use? An alternate technology that will address the XSS problem? > 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. Since the policy is mostly a list of hosts or domains it would seem difficult to shorten it much. We could make the directives terse or even cryptic, but that doesn't gain much in length nor would it help understandability. >> 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. 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. -Dan Veditz
Received on Friday, 17 July 2009 16:25:34 UTC