content security policy

teh_g

Spinning up a new topic since the old one was from 2014...

As we move into 2017, I think security will be bigger and more important. I'd love to have better support for implementing Content Security Policy that is not wide open. If I want to implement CSP, I need to add flags that add a decent amount of risk: script-src 'self' 'unsafe-inline' 'unsafe-eval'. Take a look here for a decent explanation: https://www.html5rocks.com/en/tutorials/security/content-security-policy/#inline-code-considered-harmful

While we are at it, I'd love to see a list of what pages need to be white listed with NodeBB. Looks like Bootswatch is called for CSS in the default themes and a few Google Fonts pages gets called too.

Take a look at this page as well, it is what the forums here score for some security features.

julian

@teh_g Thanks for posting!

Security of client-side assets is definitely something we're planning on implementing, CSP included.

However there is a trade-off with our current setup (which is more open, and allows plugins to pull scripts as necessary via script tag injection, etc), to one with CSP enabled, in which case some plugins may run into situations where functionality no longer works.

At this point I am not entirely certain what kinds of plugins may be affected, but it is a consideration going forward...

teh_g

@julian said in content security policy:

@teh_g Thanks for posting!

Security of client-side assets is definitely something we're planning on implementing, CSP included.

However there is a trade-off with our current setup (which is more open, and allows plugins to pull scripts as necessary via script tag injection, etc), to one with CSP enabled, in which case some plugins may run into situations where functionality no longer works.

At this point I am not entirely certain what kinds of plugins may be affected, but it is a consideration going forward...

So far, I managed to use the report only header to at least get something in place. With a few additions for my iframely setup, I was able to get my forums and admin panel to not report any potential blocks using this CSP:

add_header Content-Security-Policy-Report-Only "default-src 'self'; connect-src 'self' wss: https://api.github.com; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://iframely.gamingexodus.com https://storage.googleapis.com https://checkout.stripe.com; img-src 'self' data: https://i.imgur.com https://www.gravatar.com https://gamingexodus.com https://www.gamingexodus.com https://static-cdn.jtvnw.net; style-src 'self' 'unsafe-inline' https://maxcdn.bootstrapcdn.com https://fonts.googleapis.com; font-src 'self' https://maxcdn.bootstrapcdn.com https://fonts.gstatic.com; child-src https://iframely.gamingexodus.com; object-src 'none'";

Some comments around a few ones and where they may apply:

Any of the gamingexodus.com ones are exclusively for me, since these are for my domain
- Due to how I setup my forum, I had to add the www and gamingexodus.com versions to load some images properly. I think this is just due to how 'self' is defined
https://checkout.stripe.com
- This one was weird, it showed up on the admin page, must come from one of the plugins I have?
https://storage.googleapis.com
- Not sure what requires this
https://api.github.com
- Not a huge fan of this one, but it looks like the ACP needs it for checking the latest version
https://static-cdn.jtvnw.net
- Unique to the Twitch monitor plugin

julian

Right, that's what I mean... if we define a strict set of domains we can load third party assets from, then some plugins won't be able to function...

It's a trade-off that may be worth it, but I'm very loathe to implement it as is....

teh_g

@julian said in content security policy:

Right, that's what I mean... if we define a strict set of domains we can load third party assets from, then some plugins won't be able to function...

It's a trade-off that may be worth it, but I'm very loathe to implement it as is....

I am in the same boat. I think a big change for the backend NodeBB that will help is making the code not require 'unsafe-inline' and 'unsafe-eval'. It would probably be a huge pain, but definitely something to look forward to.

attis

@teh_g said in content security policy:

'unsafe-inline' 'unsafe-eval'

Hi guys, any luck getting rid of the above? We'd like to implement CSP for our forums but it does not make much sense (in terms of combating XSS) if we have to allow inline and eval

frju365

For my forum and the nodebb app of Yunohost, I've made a header nginx conf with like that :

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"; 
add_header 'Referrer-Policy' 'same-origin';
add_header Content-Security-Policy " default-src 'none'; connect-src 'self' https://bootswatch.com/ wss://forum.domain.tld https://api.github.com/; font-src https://forum.domain.tld/fonts/ https://maxcdn.bootstrapcdn.com/bootswatch/latest/fonts/ chrome-extension://* https://forum.domain.tld/assets/vendor/fontawesome/fonts/ https://fonts.gstatic.com/s/opensans/v15/ https://fonts.gstatic.com/s/roboto/v18/ https://fonts.gstatic.com/ https://forum.domain.tld/; img-src 'self' https://bootswatch.com/; script-src 'self' 'unsafe-inline' ; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com/ https://maxcdn.bootstrapcdn.com/; frame-ancestors 'self'";
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
add_header X-Frame-Options "SAMEORIGIN";

For information, I use the github-sso plugin : so the connect-src https://api.github.com is needed.

This conf is approved by mozilla observatory with a B+ (just unsafe-inline in style-src which is annoying.

I hope this can be a base for the future official CSP conf or at least help the dev a bit.

frju365

PS: ofc: change forum.domain.tld with your forum url.

julian

Thanks for the tips, we've implemented some of those here. I'd like to put CSP in NodeBB core itself, so that's a separate issue...

Bejan

@julian Any updates on nodebb's CSP implementation? I'd like to avoid unsafe-* for obvious reasons.