Long standing TODO.
Use a Content-Security-Policy
Not trivial to implement.
Long standing TODO.
Use a Content-Security-Policy
Not trivial to implement.
As http://kkkkkkkkkk63ava6.onion/wiki/Whonix:Privacy_policy is locked from editing, please add to the “Technical Information” table ->
HTTP Headers & Content Security
Then (in red):
D Rating. https://securityheaders.io/?followRedirects=on&hide=on&q=whonix.org Content Security Policy is not enacted, X-Content-Type-Options are vulnerable to MIME-sniffing, and Referrer Policy is not set.
Also suggest adding to the table ->
Then (in yellow or red):
The server header is advertising the software being run on the server. https://securityheaders.io/?followRedirects=on&hide=on&q=whonix.org
Maybe change HSTS to yellow also due to Mozilla Observatory not liking the strict transport security settings (but not specifying why).
Transparency with users and all that. Right now the table makes it look like everything is fine and dandy, when it isn’t.
That’s the same thing as Content-Security-Policy.
I don’t see where they are. But even if they did, with all due respect for Mozilla, we shouldn’t take it without sensible justification.
No, it’s only there for legal purposes.
No. It’s legal text. To be effective, it needs to be in German language. Until something or someone has been found to take responsibility to set up a better legal framework for Whonix. The editing of https://www.whonix.org/wiki/Datenschutz is blocked, because we cannot accept changes to the legal text. (Similar to editing the text of licenses such as GPL - very bad idea.)
The technical information part however is volunteer, not required for legal reasons. Therefore I have split it into a separate template https://www.whonix.org/wiki/Template:Whonix.org_security in case you wish to edit it further.
Certificate Authority (CA) Pinning
HTTP Public Key Pinning
You have entered just whonix.org to be scanned which is equal to http://whonix.org and the HTTP response does indeed include a HSTS header but I wouldn’t consider this to be a big problem because browsers should just ignore it (RFC 6797, sect. 8.1) on the first request and accept it after the redirect to HTTPS. If you scan https://whonix.org it doesn’t complain about the HSTS header:
The “Onebox” fearure seems to be unable to handle &-signs correctly, they show up encoded as HTML-entity
& in the URL. Here is the correct link: https://securityheaders.io/?q=https%3A%2F%2Fwhonix.org%2F&hide=on&followRedirects=on
I would consider that a feature.
If it was a feature that browsers would support you could inject this header in the HTTP traffic to execute a denial of service attack on websites that don’t have (full) HTTPS support, which is probably the reason why browsers are supposed to ignore it.
It also wouldn’t have any real advantage over being redirected to HTTPS and then getting an HSTS header which you can trust.
But adding it doesn’t really harm as long as HTTPS is supported and/or browsers keep ignoring it .
Good to know, thanks. All the website server stuff is a complete mystery to us mere mortals
Since you seem knowledgeable, how hard is it to turn these red table items into green i.e. for website maintainer? ->
I haven’t used PK or CA pinning yet, so the following is just as far as i know.
Sorry, I don’t understand your question. Could you please provide more details? Maybe you mean this?
Generally, a CSP would be great!
We don’t develop any web apps. We are using Libre Software. Mediawiki (wiki), wordpress (blog), phabricator (issue tracker) and discourse (forum). We don’t have resources to make changes on the code level. But if you wish, please feel very free to report any such issues against these projects. Because then these fixes would flow down as we update these web apps.
Which makes this require constant maintenance.
Perhaps mediawiki, wordpress, phabricator and/or discourse are providing boiler plate CSPs we just can copy/paste and are free to use? If not, could you make a feature request against these projects please?
For MediaWiki it’s an open ticket: https://phabricator.wikimedia.org/T135963
For Phabricator it’s an open ticket: https://secure.phabricator.com/T4340
For discourse I could only find a from post: https://meta.discourse.org/t/how-to-configure-content-security-policy/53308
For wordpress there is an old (6 years) plugin which allows automatic creation of the CSP header: https://people-mozilla.org/~bsterne/content-security-policy/wordpress.html
and a newer one which seems to be manual: https://de.wordpress.org/plugins/wp-content-security-policy/
I could make some CSPs which allows the use unsafe-inline code if required until those apps are compatible. This would at least prevent an attacker from embedding external sources.
You could setup a small script which logs policy violations to fix them as they occur (example).
*.whonix.org/* (in case you want to manage just one CSP for everything):
default-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src * data:; font-src 'self'; connect-src 'self'
Other CSPs I have created during my tests:
forums.whonix.org/* (the Onebox feature embeds external images from various locations):
default-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src *; font-src 'self'; connect-src 'self'
default-src 'none'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src data: 'self'; font-src 'self'; connect-src 'self'
www.whonix.org/blog/* (profile images from the forum are embedded using HTTP):
default-src 'none'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src data: https://forums.whonix.org https://forums.whonix.org 'self'
www.whonix.org/wiki/* (one image was requested from wikimedia):
default-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src https://upload.wikimedia.org 'self'; font-src 'self'
https://www.whonix.org/ (has an inline onclick event to hide the donation message):
default-src 'none'; script-src 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self'
default-src 'none'; style-src 'self'; img-src 'self'
www.whonix.org/cgi-bin/mailman/* (has an inline script):
default-src 'none'; script-src 'unsafe-inline'; img-src 'self'
www.whonix.org/pipermail/* (has an inline style):
default-src 'none'; style-src 'unsafe-inline'; img-src 'self'
Note: I’d recommend setting up an endpoint for CSP violation reports for debugging purposes in case something needs more permissions.
It’s worth noting that
unsafe-eval essentially make the CSP worthless - this still allows XSS to fire, since an XSS payload would be “inline”. I don’t have the time, knowledge, or ability to go through the myriad of software this website runs to “fix” their inline scripts.
If/when upstream projects (phabricator, mediawiki) do away with inline scripts, I would be definitely willing to take another look at this.
I have to say thanks for your hard work in making the policies, as well as your concern about our security posture. I feel like, for the time being, we have a sane balance between securing ourselves (HSTS, x-xss-protection) while avoiding potentially DoSing ourselves by setting things up wrong (HPKP, to a lesser extent CSP).
Yes, those CSPs won’t effectively stop an XSS attack, but still limit what an attacker can do and make it harder to do something useful if an XSS injection succeeds, for example interactive communication (connect-src) with remote servers is still prevented by the CSP.
The first CSP I proposed is safe enough to not DoS yourself. Even if a future application requires more permissions (for example embedding a flash object) most features will still work as expected and should remain usable, also you get a report as soon as it happens and a fix would be pretty easy (just add the missing permission, reload, done).
You could try the CSP in report-only mode for a month or so and see if it would block anything that shouldn’t be blocked or change the
'self' or even
*.whonix.org instead of
'none' which would permit applications to do anything as long as its on the same host or hosted on a Whonix subdomain (unless a more specific directive is given) if you fear DoSsing yourself.
I’m currently looking at the CSP headers (new sysadmin).
Your examples are really useful and I’ll be using those as a basis with which to achieve it.
I agree with @fortasse’s reservations, but I also agree with you that having a CSP with unsafe-inline is better than none at all for other reasons.
I was just wondering what was the purpose behind unsafe-eval? Did you find cases on Discourse or the Wiki where that was actually required?
In the time since this ticket, Phabricator actually implemented a CSP, and since we upgraded Phabricator recently, we have pulled that in. https://phabricator.wikimedia.org/T135963
It looks like MediaWiki merged in code for it recently too (March 2018), albeit they think it may break many gadgets/extensions so we’ll have to tread carefully.
Discourse is a ways off, they don’t consider it a priority/have no resources for it. Same link as you found.
I’ll be looking at adding individual CSP headers to the various other areas (ignoring /blog since that’s been sunset in favour of Discourse) soon.
Currently fighting with my own site’s CSP when under .onion, despite the .onion host being whitelisted! Grrr…
CSPs now deployed:
Whatever you are doing is working as the server is running much better than the old days. Seems upgrades etc are beneficial, as .onion is not super flaky anymore.
Extra white space on all PDF embedded links (on the right-hand side) has been noted in the wiki. Doesn’t happen with other external resources - perhaps related to the CSP policy? Can you please investigate e.g. see here for example (cookie PDF paper):
Hi @torjunkie, I confirm this is due to the Content Security Policy.
The page appears to try and add this little PDF logo from WikiMedia when a .pdf is linked to:
The CSP blocks that (on purpose).
Whilst whitelisting upload.wikimedia.org briefly in order to prove the point, I realised that when on .onion, the above URL actually is converted to http:// because of the http:// in the .onion. So this would actually break encryption for onion visitors if we were to whitelist it. I could try and rewrite the page content on the page response but it’s a bit fiddly for such a minor thing. Moreover, Patrick wanted external resources blocked in the CSP on purpose (in case someone somehow embeds an asset that has legal implications etc)
Disable the icon by using this method (if it works): https://en.wikipedia.org/wiki/Help:External_link_icons#Hiding_link_icons
Let me know what you and Patrick want to do. 1) is probably the easiest win, but requires some discipline from the page editors to remember to use the ‘plainlinks’ class when linking to external resources like PDFs.
- Disable the icon by using this method (if it works): https://en.wikipedia.org/wiki/Help:External_link_icons#Hiding_link_icons