[HOME] [DOWNLOAD] [DOCS] [BLOG] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Whonix website security rating - "B" (Mozilla Observatory) - Content Security Policy (CSP)

csp

#1

Re: Whonix website settings via Mozilla observatory. Overall whonix.org gets a “B” rating.

Everything looks pretty good e.g. ciphers used and so on (A, A+ etc), except HTTP Headers & Content Security, which gets a “D” rating.

https://observatory.mozilla.org/analyze.html?host=whonix.org

Why? The problem relates to Content Secutiry Policy, X Content Type Options and Referrer Policy

Check this output:

Missing Headers

Content-Security-Policy

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.

X-Content-Type-Options

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is “X-Content-Type-Options: nosniff”.

Referrer-Policy

Referrer Policy is a new header that allows a site to control how much information the browser includes with navigations away from a document and should be set by all sites.

It also doesn’t like the Strict Transport Security setting, for whatever reason:

Strict-Transport-Security

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS. That said, the HSTS header must not be returned over a HTTP connection, only HTTPS.

It also seems to suggest the server advertises the software running it, but sometimes that can be configured to be hidden:

Server

This Server header seems to advertise the software being run on the server but you can remove or change this value.

The links at the website show how the website maintainer can address these issues with various settings. It doesn’t look like rocket science. See:

https://scotthelme.co.uk/a-new-security-header-referrer-policy/
https://scotthelme.co.uk/content-security-policy-an-introduction/
https://scotthelme.co.uk/hardening-your-http-response-headers/

Hopefully fixable.

Cheers


#2

Long standing TODO.

Use a Content-Security-Policy
https://phabricator.whonix.org/T70

Not trivial to implement.

//cc @fortasse


#3

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

Server Security

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.

Also, a privacy policy should really be available in English. Shall I run that German stuff on the same page through Bing translator and fix up the quirky English result?


#4

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.

Yes.

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.


Also addded:

Certificate Authority (CA) Pinning
https://phabricator.whonix.org/T66

HTTP Public Key Pinning
https://phabricator.whonix.org/T84


#5

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:
https://securityheaders.io/?q=https%3A%2F%2Fwhonix.org%2F&hide=on&followRedirects=on

Edit:
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


#6

Hexagon:

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 […]

I would consider that a feature.


#7

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 .


#8

Good to know, thanks. All the website server stuff is a complete mystery to us mere mortals :wink:

Since you seem knowledgeable, how hard is it to turn these red table items into green i.e. for website maintainer? ->

http://kkkkkkkkkk63ava6.onion/wiki/Datenschutz#Technical_Information


#9

CSP:

  • Generating the headers should be quite easy, depending on the granularity. I’d suggest creating one for each application (wiki, blog, forum, phabricator) starting with a restrictive report-only version and when no more reports come in enforcing it.
  • Making the headers more effective (i.e. not using unsafe options) is a bit harder as this would require some code changes. Currently you are using some inline-JS and inline-CSS which would be ideally moved to a file or at least get a hash or nonce.
  • And you are using some style-Attributes which are can’t get a hash or nonce and thus can be used only with unsafe-inline, these should be replaced by css classes if possible
  • The CSP header might has to be modified if an application changes

I haven’t used PK or CA pinning yet, so the following is just as far as i know.

PK pinning:

  • Requires two certificates using different public keys in case one has to be revoked
  • It’s dangerous! Start with short time periods and test both certificates
  • If you get a new public key you have to update your header soon enough to include it during a transitional period
  • After testing you shouldn’t have to touch it until you plan to get a new key pair

CA pinning:

  • Requires two certificates from different CAs in case one has to be revoked
  • Less dangerous, but still start with short time periods and test both certificates
  • If you change your CA or they get a new public key you have to update your header soon enough to include it during a transitional period
  • After testing you shouldn’t have to touch it until you change your CA or your CA gets a new key pair to sign certificates

#10

Sorry, I don’t understand your question. Could you please provide more details? Maybe you mean this?

{{Yes}}

Or.

{{No}}

#11

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?


#12

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


#13

CSP for *.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:

CSP for 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'

CSP for phabricator.whonix.org/*:

default-src 'none';
script-src  'self' 'unsafe-inline';
style-src   'self' 'unsafe-inline';
img-src     data: 'self';
font-src    'self';
connect-src 'self'

CSP for 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: http://forums.whonix.org https://forums.whonix.org 'self'

CSP for 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'

CSP for 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'

CSP for https://www.whonix.org/download/:

default-src 'none';
style-src   'self';
img-src     'self'

CSP for www.whonix.org/cgi-bin/mailman/* (has an inline script):

default-src 'none';
script-src  'unsafe-inline';
img-src     'self'

CSP for 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.


#14

It’s worth noting that unsafe-inline and 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).


#15

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 default-src to '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.


#16

Hi @Hexagon,

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…


#17

CSPs now deployed:


#18

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.