Shutting Down XSS with Content Security Policy http://blog.mozilla.com/security/2009/06/19/shutting-down-xss-with-content-s...
I'm usually the first to complain about applying technical solutions to problems which are not fundamentally technical... but this looks like it would be reasonably expedient to implement.
While it won't be effective for all users the detection functionality would be a big improvement in wrangling these problems across the hundreds of Wikimedia projects, many of which lack reasonable oversight of their sysop activities.
On Mon, Jun 29, 2009 at 6:36 PM, Gregory Maxwellgmaxwell@gmail.com wrote:
Shutting Down XSS with Content Security Policy http://blog.mozilla.com/security/2009/06/19/shutting-down-xss-with-content-s...
I'm usually the first to complain about applying technical solutions to problems which are not fundamentally technical... but this looks like it would be reasonably expedient to implement.
While it won't be effective for all users the detection functionality would be a big improvement in wrangling these problems across the hundreds of Wikimedia projects, many of which lack reasonable oversight of their sysop activities.
I think this would be reasonable to consider implementing as soon we have a significant number of users using it. It isn't a good idea to make CSP policies that won't actually be effective immediately for a lot of people, because then we'll probably use it incorrectly, break tons of stuff, and not even notice for months or years (possibly even harming uptake of the first version of Firefox to support it).
This does seem to be Mozilla-only, though. If it were an open specification that multiple vendors were committed to implementing, that would make it significantly more attractive. I wonder why Mozilla isn't proposing this through the W3C from the get-go.
We'd have to do some work to get full benefit from this, since we currently use stuff like inline script all over the place. But it would be fairly trivial to use only *-src to deny any remote loading of content from non-approved domains, and skip the rest. That would at least mitigate XSS some, but it would stop the privacy issues we've been having cold, as you say.
On Mon, Jun 29, 2009 at 7:56 PM, Aryeh GregorSimetrical+wikilist@gmail.com wrote:
I think this would be reasonable to consider implementing as soon we have a significant number of users using it. It isn't a good idea to make CSP policies that won't actually be effective immediately for a lot of people, because then we'll probably use it incorrectly, break tons of stuff, and not even notice for months or years (possibly even harming uptake of the first version of Firefox to support it). This does seem to be Mozilla-only, though. If it were an open specification that multiple vendors were committed to implementing, that would make it significantly more attractive. I wonder why Mozilla isn't proposing this through the W3C from the get-go.
When to do it is a philosophical issue:
Arguably it should be turned on early so that the early adopters of the technology (i.e. firefox devs!) will be test subjects. Support for audio/video tag in Wikipedia has been helpful in the development of firefox audio and video tag support. If the feature is turned on only once these clients are widely deployed then we'll have a situation where things may be broken for many users.
So— turn it on early and have many things will broken for a small number of technically savvy users, up to the point potentially slowing the adoption of a future browser release. ... or turn it on later when it will likely cause a few problems but for 30% of the sites visitors?
The latter sounds like too much of a flag-day.
The stuff likely to stay broken after the initial implementation are things like userscripts. Those are just going to take a long time to fix no matter what. The best thing there would be to communicate the correct practices well in advance so that the natural development cycle picks them up, but I'm not aware of any way to communicate such a thing except by making the wrong ways not work.
We'd have to do some work to get full benefit from this, since we currently use stuff like inline script all over the place. But it
Right, though with all the minification interest I've seen here lately it sounds like a great time to hoist all that stuff out of the pages.
would be fairly trivial to use only *-src to deny any remote loading of content from non-approved domains, and skip the rest. That would at least mitigate XSS some, but it would stop the privacy issues we've been having cold, as you say.
I think one really compelling thing about it is that supporting clients can provide feedback to the webserver. This means that every supporting user will be an XSS test probe, a canary in the page-mine. So even if this doesn't become standardized and widely adopted by clients other than firefox it would reduce the damage of unintentional but well meaning privacy leaks since we'd get notice of them very quickly rather than months later.
Hopefully this will be more widely adopted, because I think that the available knobs provide a level of functionality which we couldn't achieve any other way. (i.e. we could deny html/script injection completely in mediawiki, but limiting scripts to accessing particular domains isn't something mediawiki could reasonably do itself)
I don't know enough to comment on the W3C path— but I have no particular reason to think it wouldn't happen: W3C activity is almost universally lagging rather than leading. Things like this aren't generally matters for discussion unless someone is thinking of implementing them.
On Mon, Jun 29, 2009 at 9:37 PM, Gregory Maxwellgmaxwell@gmail.com wrote:
When to do it is a philosophical issue:
Arguably it should be turned on early so that the early adopters of the technology (i.e. firefox devs!) will be test subjects. Support for audio/video tag in Wikipedia has been helpful in the development of firefox audio and video tag support. If the feature is turned on only once these clients are widely deployed then we'll have a situation where things may be broken for many users.
I was thinking we should wait until we have at least a few devs/sysadmins using a browser that supports it. I've had bad personal experience with trying to write to standards without being able to test the effects. I tried adding handheld stylesheet support to MediaWiki without actually using mobile devices much myself -- and someone from Opera ended up posting to wikitech-l politely suggesting that we should scrap the stylesheet because it was trash and their automatic adaptation of the screen stylesheet worked better. Similarly, I've been reluctant to do any work on RTL, although I can read Hebrew, because I use RTL wikis rarely and wouldn't be sure I'd be improving things for the actual users.
The people writing the code need to be able to see firsthand how it's working as they develop it, and preferably be noticeably affected by any errors they make. So when Firefox alphas support this and some devs actually start using them, that's when I'd say we should start actually writing the support. The syntax might even still change at this point, for all I know.
Right, though with all the minification interest I've seen here lately it sounds like a great time to hoist all that stuff out of the pages.
Some of it will be fairly hard, though. How are we going to set all the page-specific variables, with an extra request? Also, while replacing inline scripts and on* attributes with event handlers is fine in theory, practically speaking it's not always as good (at least, to the limits of my meager JavaScript knowledge).
For instance, notice how some infoboxes sometimes load and then suddenly collapse after a second, when they're meant to be collapsed by default for JS-enabled clients but expanded by default for non-script clients. I don't know if this is happening right now, but I've seen it before. The cause is that the script is run at the top of the page. At that point it can't collapse the infobox, because the infobox hasn't been added to the DOM yet. So it adds an onload event handler -- but that only fires after the page has fully loaded, a noticeable period after the fully-expanded infobox has been rendered. With inline style you could just do:
<div class="infobox"><script>// Set display: none on the div after that has been added to the DOM, but before its contents</script>...
. . . I guess in this case you could set a CSS rule from the JavaScript before the div is actually created. But not all "immediately after parsing" DOM manipulation is CSS-based. Say you wanted to add some buttons on page load that only have an effect when JS is enabled, like collapse/expand links. This is what we do now for TOCs:
<script type="text/javascript"> //<![CDATA[ if (window.showTocToggle) { var tocShowText = "show"; var tocHideText = "hide"; showTocToggle(); } //]]> </script>
Is that possible to do without inline script, without causing jumping or other undesirable effects (e.g., useless links being shown to some users)?
I think one really compelling thing about it is that supporting clients can provide feedback to the webserver. This means that every supporting user will be an XSS test probe, a canary in the page-mine. So even if this doesn't become standardized and widely adopted by clients other than firefox it would reduce the damage of unintentional but well meaning privacy leaks since we'd get notice of them very quickly rather than months later.
I didn't notice that feature on my first pass through the spec. That is really neat, since you point it out. It would also help for figuring out when content is inadvertently breaking. It mitigates my objections above to speedy implementation, although I still think waiting until we have an actual preliminary implementation is a good idea. Specs tend to change based on implementation experience.
I don't know enough to comment on the W3C path— but I have no particular reason to think it wouldn't happen: W3C activity is almost universally lagging rather than leading. Things like this aren't generally matters for discussion unless someone is thinking of implementing them.
Yes, but Mozilla can create a new working group to develop the spec in if they want to make the functionality standard, like they did with CORS. They don't seem to be doing that (yet?). It's still early, though, and maybe they plan to.
wikitech-l@lists.wikimedia.org