content security policy



  • Re: Helmet - Express Middleware

    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.


  • Admin

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



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

  • Admin

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



  • @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.


Log in to reply
 

Looks like your connection to NodeBB was lost, please wait while we try to reconnect.