Content Security Policy; Great! or Wait?

A couple of days ago I had another look at Content Security Policy, a technology that allows a site to tell a browser resources are allowed to be loaded to protect against XSS and some other types of web application vulnerabilities. CSP was originally devised by the Firefoxians, but is in the process of being standardized by the W3C with support in Firefox, Chrome, Safari and even the upcoming Internet Explorer 10.
Great!
The functionality offered by CSP (blocking requests that are not allowed) is pretty close to what WP DoNotTrack tries to do, so I decided I’d try to integrate CSP in my plugin, based on the following assumptions:

  • CSP-mode will only work for WP DoNotTrack if it is configured to use a whitelist
  • As most WordPress+plugins installations are bound to have pages with at least inline JavaScript and/or style, I have to add “unsafe-inline” to allow those to continue to work (which indeed limits the level of protection against XSS-attacks)
  • Given that a lot (most?) WordPress installations implement WP Super Cache of W3 Total Cache, it will -at least in a first stage- only kick in if WP  DoNotTrack is configured to filter unconditionally
  • Ideally the JavaScript-based component of WP DoNotTrack would “see” that CSP was activated and would not perform those nifty JavaScript AOP trickery

The “proof of concept”-quality code I ended up adding to wp-donottrack.php was pretty simple:

function wp_donottrack_csp() {
 global $listmode;
 if ($listmode==="1") {
  $whitelist=wp_donottrack_getWhiteList(true);
  $csp="default-src 'self' 'unsafe-inline'";
  if (is_array($whitelist)) {
   foreach ($whitelist as $white) {
    $csp.=" *.".$white;
   }
  }
  header("X-Content-Security-Policy: " . $csp); //FF & MSIE10
  header("Content-Security-Policy: ". $csp); //new standard
  header("X-WebKit-CSP: " . $csp); //chrome & safari
 }
}
add_action('init', 'wp_donottrack_csp', 10, 0);

Wait?
With this code on my testblog I started playing around in a couple of browsers. Based on that experience I found the following limitations:

So in this particular context (and specifically the absolute need for “unsafe-inline”), I’ve decided to hold off implementing CSP (I might implement iFrame sandboxing as support for that is coming with IE10 and will probably also land in Firefox 17). But if you have full control over a particular website or -application (meaning you can remove all inline JavaScript and CSS and all instances of evals in insourced JavaScript) and you want to harden your installation to stop cross-site scripting, you really should start thinking about implementing CSP (as Twitter seems to have done already)!

Firefox preferences for greater privacy

Although browser addons such as NoScript and Ghostery (which is cross-browser with some limitations) provide great protection against tracking, some people prefer not to have to install plugins. Firefox does have configuration options to somewhat limit what trackers can do. You can follow the knowledge base article here to learn how to disable 3rd party cookies (the default setting in Safari, which Google was caught circumventing).
If you’re up to it, you also simply open up the almighty “about:config” and tinker with the following settings (some of which aren’t available in the browser UI):

  • network.cookie.cookieBehavior with values:
    • “0”: allow all cookies (default)
    • “1”: don’t allow 3rd party cookies
    • “2”: don’t allow any cookies
  • network.cookie.thirdparty.lifetimePolicy with values:
    • “0”: keep cookies for as long as the server asks
    • “1”: ask the user on each and every cookie set (try it out if only for fun, you’d be surprise how much cookies are set)
    • “2”: cookie gets deleted when you close your browser (i.e. at the end of the session)
    • “3”: cookies have a lifetime as defined in the “network.cookie.lifetime.days ” preference
  • network.cookie.thirdparty.sessionOnly: set to “true” or “false”
  • privacy.donottrackheader.enabled: set to “false” (default) or “true”, which gently asks sites not to track you

Setting “network.cookie.thirdparty.sessionOnly” to “true” is a low-impact change which should stop tracking-companies (think Media6degrees or Quantcast) from following you around the web.
If you want to stop Facebook, Google & Co to stop tracking you around the web as well, the above setting will not suffice. You should either log out of their sites as soon as you’ve done your business there or set “network.cookie.cookieBehavior” to “1” (which will break their “social widgets”). Or you can install Ghostery or NoScript, off course.

Iframe sandboxing support coming soonish

Did you know you can limit the damage an iframe can do by adding the “sandbox” attribute? And that you can add a value to that attribute to loosen your grip if you choose to do so?
I remember reading about this a couple of years ago or so, but forgot as  support for this html5 spec was limited to Chrome (Apple added support in Safari as well). But while investigating a problem a WP DoNotTrack-user was facing, I re-discovered iframe sandboxing (it effectively stopped the javascript-based tracking inside the iframe) and noticed that support for it is to be included in Internet Explorer 10 and that Mozilla is finally working on an implementation as well.
So yeah, the option to sandbox iframe’s pointing to blacklisted (or non-whitelisted) hostnames will probably be in a future version of WP DoNotTrack. Stay tuned!

Firefox 6 on Ubuntu Linux swapping like crazy

Firefox 6 got pushed on my Ubuntu 11.04 netbook as an update a couple of days ago and things were badly broken; memory usage was skyrocketing, the kswapd was eating almost all CPU and the system was pretty much in a continuous wait-state.
After some cursing and a lot of Scroogling, I finally stumbled across this blogpost which described the exact same problem and advised to set  “layers.acceleration.force-enabled” (which tries to force hardware acceleration, which isn’t supported on Linux by default) back to “false” in about:config. And indeed this small rollback solved my memory-woes. Guess I shouldn’t have dismissed that silly about:config warning message after all.
And while we’re on the subject; Firefox 7 should see substantial improvements in memory usage, yay!

Code Rush: watching Mozilla’s history in the making

A couple of days ago I saw “Code Rush“, a non-fiction movie about life at Netscape while they were in the process of open sourcing their browser in 1998. It’s a great documentary about a defining moment in the history of the web, touching on subjects like code & quality (zarro boogs), the fight with Microsoft, the awkward marriage with AOL, the stock market, technology start-up culture and work versus life.

Netscape Mozilla Documentary 1998 - 2000 ProJect Code Rush - creative common licence

Open sourcing Communicator didn’t save Netscape as a company, but it did allow the Mozilla Organization to create a whole new browser suite based on XUL and NGlayout (later Gecko), which were 2 important building blocks for Phoenix, a standalone browser (instead of a suite) which we now know as Firefox.
Code Rush aired in 2000 on PBS in the States, but was released under a Creative Commons license in 2009. You can check out all footage (and search the transcripts) on clickmovement.org.

But how unstable is Flash really?

You probably read that  Steve Jobs officially declared Flash a stability nightmare and that Adobe’s CEO responded that OS X is to blame. Hard to take sides in this blame-game, especially without access to Apple’s crash reports data. We do, however, have access to Mozilla’s crash-stats.mozilla.com. Could those figures provide us with at least some relevant statistics about Flash’s reliability?
I imported this csv-file with the top 300 crashers for Firefox 3.6.3 for the last 50 days (3.6.3 was released on April 1th) into a Google Docs spreadsheet and counted the number of crashes for each line where “Flash” or “NPSWF32” is in the signature (SUMIF without wildcard characters, seriously Google!?). You can find the spreadsheet here, but these are the results:

total number crash reports for top 300 crashers:3583582
crash reports with “NPSWF32” or “Flash” in signature:1154488
flash-related crashes %:32.22%

That’s right; almost 1/3 of the Firefox 3.6.3 “top crashers” are clearly related to Flash! So yes, there is good reason to consider plugins in general and Flash in particular a stability risk for Firefox. And for the record, the numbers for Mac seem to indicate that the problem is even (much) worse there! So hurray for Firefox 3.6.4 with Out of Process Plugins! And hey Adobe, get your Flash together!

Firefox Lorentz: Flash don’t crash here anymore

A couple of days ago I installed Lorentz, a beta version of Firefox. Lorentz is virtually identical to Firefox 3.6.3, except that it incorporates part of the work of the Electrolysis team. Their “Out-of-process plugins”-code lets Firefox-plugins (on Windows & Linux, they’re still working on Mac OSX according to the release notes) run in a separate process from the browser, meaning Flash (but also Silverlight or Quicktime) can’t crash Firefox any more.
This feature actually is long overdue, a substantial amount of Firefox crashes are indeed caused by Flash failing and Mozilla’s competitors (MS IE, Apple Safari and Google Chrome) already have similar (or even more exhaustive) crash-protection.
Once you’ve installed Lorentz (or Chrome or IE8 or Safari off course) you can safely visit http://flashcrash.dempsky.org/, which exploits a bug that was reported 19 months ago and which may still cause the most recent Flash-version (10.0.45.2) to crash. And if flashcrash doesn’t bring up the plugin-crash-dialog, you can always kill the “mozilla-runtime” process that hosts the plugins, just for kicks!

x-frame-options coming to a Firefox near you

Microsoft IE8 introduced it, Apple Safari4 has it, Google Chrome4 does it and now somewhere in the not too distant future, Firefox will ship it too; support for X-FRAME-OPTIONS.
X-cuse-me? Well, X-FRAME-OPTIONS is the HTTP response header that broke Google Talk chat badge a few months ago, remember? It allows you to specify whether your site or page can be (i)framed or not, by setting it to “DENY” (not allowed to be framed) or “SAMEORIGIN” (allowed if the framing site is on the exact same domain). The most important reason for this functionality is as a prevention-mechanism for “clickjacking” (a.k.a. UI redressing), a type of web attack that tries to trick victims into clicking a framed site by hiding it behind another innocent element.
So now that feature is finally coming to Firefox as well; Mozilla’s Brendan Sterne, one of the driving forces behind Mozilla’s much broader content security policy, grabbed the bug by the balls and came up with a first patch. If all goes well, this would be an ideal candidate to get pushed out with a minor version update as per the new release process, no?

Browser choice, vacuming & security for father-in-laws

Being “the computer guy” in the family might be a pain in the ass sometimes, but trying to help out users that are not tech savvy can be very revealing. Yesterday my father-in-law asked me to take a look at his computer, there was something about the browser that was not right. Turned out he let Google lure him into downloading Chrome and making it the default browser. What bothered him most about Chrome was the lack of menu’s (file|edit|…|help), while a lot of the us (the in-crowd) consider the minimal use of chrome a plus. Usability is not only about clean, simple UI’s, but also about not breaking novice users’ expectations of how your application looks and behaves.
Anyway, I showed him IE8 and Firefox 3.5 (both were installed as well) and he recognized Firefox as the browser he was most familiar with. So I uninstalled Chrome, hid IE8, upgraded him to FF 3.6 and also installed the “Vacuum Places improved” and NoScript add-ons.
Vacuum Places improved” cleans up the places sqlite database where Firefox stores bookmarks and history and which can become very big over time.  When tweaking the options (“hide icon” and “auto-vacuum every 20 browser starts”) it was a great way to invisibly tune browser performance, but it turns out Firefox 3.6 vacuums places.sqlite automatically (when  idle, every 1 to 2 months). So Pierre, if you ever read this; remind me to uninstall “Vacuum Places improved” next time! 🙂
NoScript is a whole other beast; it is a add-on for the security-conscious tech-head, which by default disables javascript, flash, java, … It’s a great add-on, but it is very disruptive and as such totally unfit for novice users. Unless you change the configuration off course, because modifying these options makes NoScript a must-have addon for both you and your grandma;

  • General: check “Scripts Globally Allowed (dangerous)”
  • Embeddings: uncheck the 8 “Forbid” options, check both “untrusted” and “trusted” for Clearclick protection
  • Appearance: uncheck “Status bar icon”, “Status bar label” and “Contextual menu”
  • Advanced/XSS: check “Sanitize cross-site suspicious requests”

Although the first option specifically claims it is dangerous to do so, these changes render NoScript into an add-on that provides a lot of extra security (protecting against clickjacking, cross-site scripting and implementing support for x-frame-options and Strict Transport Security) without bothering users with new UI-elements containing incomprehensible questions, messages or options.
Because web security is not only about protecting against threats, but also about not breaking novice users’ expectations of how your secured browser (and the web) looks and behaves.