unsafe-inline

CSP: doing unsafe-inline the Firefox-way

by

A couple of weeks ago I sobbed because of the lack of support for “unsafe-inline” in Firefox. There’s some Mozillians working on that (for CSS, at least), but given the release-train, that’ll probably only appear around Firefox 19. While perusing CSP-related tickets in Bugzilla however, I came across an interesting comment:

Firefox expects “options inline-script eval-script” instead of “script-src ‘unsafe-inline’ ‘unsafe-eval'” which it should be per spec. Also, Firefox expects “xhr-src” instead of “connect-src”.

Come again? So I can tell Firefox to execute inline script even without support for CSP 1.0 after all? I opened up my development-version of WP DoNotTrack to rework the “proof of concept”-code into this:

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;
   }
  }
 // old-style options inline-script for firefox
 $csp.="; options inline-script;";
 header("X-Content-Security-Policy: " . $csp);
 header("Content-Security-Policy: ". $csp);
 // needed for chrome, but safari 5 (latest version on windows) might be broken?!
 header("X-WebKit-CSP: " . $csp);
 }
}

Based on limited testing, it indeed seems to work great this way. So maybe -if this also turns out to work in IE10 and on Safari for Windows- a next version of WP DoNotTrack can ship with CSP-support after all?

Content Security Policy; Great! or Wait?

by

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)!