Remove remaining CSP issues

[SISheogorath]

Since #585 we are able to configure the HSTS policy provided by helmet.

Let's take the next step to modern web security and add a Content-Security-Policy.

This can be done by helmet, too. Details about how to do this can be found here:
https://helmetjs.github.io/docs/csp/

Keep in mind we should allow people themselves to enable and extend them. We want to ship secure defaults, so they should be enabled by default.

Also, keep in mind that we have the usecdn option which will include external sources. These should be added when usecdn is enabled, while it shouldn't be allowed to use them by default when usecdn is disabled.

Last but not least there is some validation work to do. Make sure that the features page is successfully rendered by default. Including all external embeddings like YouTube, Disqus, Google Analytics and more.

Pull Requests are very welcome ❤️

This is maybe interesting for someone who wants to work on web security and learn about the current technologies.

Some background information:

• Introduction to CSP
• Secure-headers.io for policy validation
• A little collection of knowledge about CSPs

[literalplus]

Since I also did #585, I'd like to do this one too. I figure that this will probably turn out to take some more time, since it also includes testing all features, plus figuring out all the external services.

Will we allow all images? I figure if we are only going to allow images from the configured provider, users will not be able to specify custom URLs, which doesn't seem like nice UX. (Of course a whitelist could be configurable if deemed a valid use case)

Also, is the feature list at /feature complete? (meaning if all issues there and the login/register form are fixed, there won't be any issues with variations?)

[literalplus]

Update, looks like there is a significant number of inline styles in the views:

➜  views git:(master) ✗ grep -i --color -r "style=" . | wc -l
81

I'll be cleaning these up first in a separate PR, I guess. Using unsafe-inline for these relatively few doesn't seem like a viable 'solution' to me.

In unrelated news, helmet didn't promise too much, sending the headers is really straightforward.

[SISheogorath]

Awesome! ❤️ I love to hear/read this!

The /features page should cover almost everything. We have to check the published notes and the slide-mode, but these are listed as features.

For now, I think we can go for these rules:

• images, Audio, and Video should be allowed from everywhere
• Inline CSS is fine
• iframes from everywhere are allowed (probably breaks wanted embeddings)

We should allow disabling these UX-friendly rules and restrict them to the real minimum, but that shouldn't be a problem.

I'm not completely sure what the ideal rules for fonts are, but that's something we can figure in this thread or with issues that open up afterward.

If we ware not sure about how to handle something we should block it until someone complains about it. This way we should get tight defaults.

---

Yes, removing the inline styles from the view sounds like a good idea.

I'll make sure we get these changes in as soon as possible.

[literalplus]

Status update: The rules are working, I got the slide view to work completely (for some reason I started there). MathJax was using inline script blocks for configuration that were later sent though eval(). I moved these to a separate file and changed the syntax a little as per their recommendations.

From a short look, we probably won't be able to disable inline CSS even in the long run - some JS libs seem to be using it. I started externalising some of the inline styles, but some of them are dynamic.

The issue I'm facing currently is that some libraries are loaded using the (apparent) Webpack equivalent of a global <script> tag, the script-loader plugin. That one only supports eval() though, and that is denied because I'd rather not include unsafe-eval in script-src. That project's CSP policy is simple: Don't use this plugin with CSP. (No alternatives linked)

Here is the problematic section in the Webpack config:

https://github.com/hackmdio/hackmd/blob/053e616be5a7283922cd8ea53b719644367d87fb/webpackBaseConfig.js#L187-L202

Simply removing the script! prefix removes the warnings, but the libraries aren't available either. (lots of browser errors about undefined things)

Any advice on how to continue from there? I haven't looked into what these libraries are for yet, but I hope there's another way to include them.

Update: Temporarily allowing unsafe-eval, I've been able to test the rest - it seems to be working quite well, except for the speaker notes in slide mode. These are broken because they're one huge inline script. No idea how to fix them since they seem to be defined entirely in the library. I also had to allow everything in object-src (applets etc.) for Chrome's PDF viewer.

Another thing I noticed is that some of the integrations are still using HTTP URLs. That may need to be fixed.

Update: This is my current status: https://me.l1t.li:1337/features

[SISheogorath]

This is already amazing!

I currently think about the best way to solve the script-loader problem. We can maybe have a chat on gitter about it in detail.

I have to verify a lot of things because I understand why they do it, as they do it, but finding a better implementation for it without breaking things is not that easy.

[literalplus]

Sure! I've joined the room on gitter, so if you have any idea, text me there. We seem to be using a deprecated version of Webpack (1.x), so maybe there's a better solution in a more recent version. I doubt this though because it doesn't seem there's an obvious way around eval for global script blocks without module support on the library side.

The options I see so far are:

• allowing unsafe-eval (unsafe)
• migrating to other libraries that have proper module support (effort)
• maintaining custom forks of these libraries with module support patched in (continuous effort)
• finding a loader that can inject nonces or include allowed files using <script>

[thegcat]

I see a CSP violation in Safari on an instance we host as well as on the Heroku instance. The error is:

Refused to execute a script because its hash, its nonce, or 'unsafe-inline' does not appear in the script-src directive of the Content Security Policy.

Safari locates the error at <the-hash-of-the-pad>:0, so line 0 of the HTML, which probably isn't very helpful. If anyone knows more about debugging this in Safari let me know and I will try to see if I can figure it out.