Tails

#1 Updated by mercedes508 2017-07-13 13:06:42

• Status changed from New to Confirmed

#2 Updated by intrigeri 2017-07-13 18:30:16

• Priority changed from Normal to Low

The attack surface of our website wrt. XSS and alike is pretty small: there’s not much “session data” to steal (I doubt anyone uses ikiwiki passwordauth account there). So to me that’s low priority, unless a stronger rationale is provided. Note: I’m not an expert at website/webapp security so I might be saying totally stupid things here :)

#3 Updated by Anonymous 2018-01-19 10:34:38

• Subject changed from Implement CSP to Implement CSP HTTP header

#4 Updated by Anonymous 2018-01-19 15:57:10

• related to Feature #15060: Apply a more restrictive CSP in Verification Extension added

#5 Updated by intrigeri 2018-03-01 07:54:01

• Status changed from Confirmed to In Progress
• % Done changed from 0 to 10

FWIW I’ve tried Mozilla’s Laboratory (Content Security Policy / CSP Toolkit) add-on, browsed our website a little bit (including going through the ISO verification process and visiting pages that inline images from 3rd-party sites) and it generated the following CSP:

default-src 'none';
connect-src 'self';
font-src 'self';
img-src 'self' https://etcher.io https://labs.riseup.net https://raw.githubusercontent.com https://rufus.akeo.ie https://translate.tails.boum.org;
script-src 'self' 'unsafe-inline';
style-src 'self' 'unsafe-inline' 

I think all this is good and could safely be applied as-is (I don’t think we should load fonts, JS or CSS from anywhere else) except:

• img-src: clearly we’re using 3rd-party images more and more, e.g. from upstream websites (Etcher, Rufus), and we can’t predict what will be the next origin we add, so I think the best we can do is to set img-src: https:.
• We could probably upgrade to default-src: https:.
• We could probably add object-src 'none' for additional safety.
• Regarding script-src’s unsafe-inline: it seems needed only for the mirror pool code in wiki/src/templates/page.tmpl, that we’ve never modified since it’s been added, so we could use the nonce mechanism (or even the sha-* one but the security benefit seems tiny compared to the maintenance cost). Unless we can set CSP via .htaccess, it will require updating the webserver config every time we add a new inline script but apparently we’ve done that exactly once in the past, so IMO it’s not a big deal (and once we have Feature #14588 it’ll become even easier to change that config, e.g. by sending pull requests to the sysadmin team).

Next step: test if we could define the CSP via our .htaccess (we already do Header append Cache-Control must-revalidate so it does not seem crazy). If we can do that then this ticket becomes a web dev security task instead of a sysadmin one and it’ll be much easier to implement this with careful iterations.

#6 Updated by intrigeri 2018-03-01 07:54:53

• Assignee set to intrigeri

(I’m tentatively assigning this to me because it could be a good opportunity for structured procrastination, but don’t hesitate stealing it from me!)

#7 Updated by intrigeri 2018-08-18 09:42:08

• blocked by Feature #14588: Self-host our website added

#9 Updated by intrigeri 2018-11-11 10:46:41

• Assignee deleted (intrigeri)
• Type of work changed from Sysadmin to Website

This can (and probably should) be implemented 100% in our website templates => nothing requires sysadmin skills or privileges here. Note that this project requires the buy-in and cooperation of tech writers and mirror pool JS developers, who will all probably be busy with higher-priority matters than protecting a basically non-existing set of people against XSS. So I suggest we either reject this during the next ticket triaging session or refocus its scope to be about our dedicated blueprints wiki (Feature #9174): if that ever gets implemented, chances are that many of us will use some sort of authentication and then protecting against XSS will make more sense there.

#10 Updated by Anonymous 2018-11-12 14:04:46

• Assignee deleted (None)

I think it would also prevent loading external sources from untrusted domains / hosts, i.e. in current blueprints.

This for example would allow to load files with the same origin as our website, plus inline JS and inline CSS (I did not check if we need this but I would suppose so):

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'unsafe-inline'; style-src 'unsafe-inline'">

One would need to grep the repository to see what other directives we might need (ajax sources for example).

If it’s just a meta to add: let’s do it.

Also see https://stackoverflow.com/questions/30280370/how-does-content-security-policy-work#30280371 for a quick overview.

#11 Updated by Anonymous 2018-11-14 11:17:09

• related to Bug #16078: Download page is not refreshed when verification extension is installed added

#12 Updated by Anonymous 2019-03-18 16:02:56

• Status changed from In Progress to Rejected

Puh, whatever.