Use Content-Security-Policy to harden the WUI

[freddyb]

I have audited the WUI and the current use of JavaScript would make it very easy to adapt content-security-policy as a defense-in-depth mechanism against XSS and other content-injection attacks against the WUI.

AFAIU one would only have to whitelist a few script files for the download-status-timeline. Everything else could easily work with "no scripts allowed".

A more moderate approach could be "only allow same-origin resources", which could be patched into the WUI similarly to what my X-Frame-Options patch does. See ticket #1455.

[daira]

​http://content-security-policy.com/ says which browser versions support which CSP headers. Basically, if we duplicate the Content-Security-Policy header to X-Content-Security-Policy and X-Webkit-CSP, we get support in earlier/more browsers.

[freddyb]

The prefix has mostly been used by those browsers that update themselves, so I guess the impact is negligible. The notable exception here is probably iOS 6.1, since updates depend on the hardware here (cf. ​http://caniuse.com/#search=CSP)

[daira]

Let's include these headers:

Content-Security-Policy: sandbox
X-Content-Security-Policy: sandbox
X-Webkit-CSP: sandbox
X-Frame-Options: DENY

(The first three are CSP; the last one is for framebusting #1455).

[daira]

Here is the code that normally renders a file: src/allmydata/web/filenode.py@5d404db8#L157​

[daira]

See branch ​https://github.com/tahoe-lafs/tahoe-lafs/commits/2136-csp-sandbox_0