Implement CSP about rockylinux.org-hugo HOT 16 CLOSED

Fixed with 660bd39

from rockylinux.org-hugo.

Hi, thanks for implementing this change. However, what you implemented adds no security benefit at all.

"unsafe-inline" is effectively zero protection. You need to whitelist the resources the site uses and move any inline javascript to external files. I'll be happy to add a PR later, but not right now.

from rockylinux.org-hugo.

@remyabel As mentioned previously, we're using Hugo to generate values in the JavaScript, and Hugo templating cannot be used in JavaScript, unfortunately, meaning we'd need to hardcode the values, which won't be sustainable for various reasons.

While I appreciate the concern, the site doesn't really load any external resources (other than links), so this effectively shouldn't be a problem. I think this StackOverflow user explains it quite well: https://stackoverflow.com/a/44698400

We're happy to get your contributions towards improving the policy otherwise, though! Just keep in mind that the way we're generating the values into the JavaScript wouldn't be sustainable any other way. :))

from rockylinux.org-hugo.

@remyabel As mentioned previously, we're using Hugo to generate values in the JavaScript, and Hugo templating cannot be used in JavaScript, unfortunately, meaning we'd need to hardcode the values, which won't be sustainable for various reasons.

What you did was hard-code it in the index.html file, but this article shows how you can generate it from Hugo. And a whitelist is going to involve hard-coding. It is a whitelist after all. I'm sure you can programmatically add to the whitelist but that's beyond the scope of this discussion.

While I appreciate the concern, the site doesn't really load any external resources (other than links), so this effectively shouldn't be a problem. I think this StackOverflow user explains it quite well: https://stackoverflow.com/a/44698400

XSS is only one attack vector and not the only one. As I said earlier, static websites can still suffer from data injection attacks. This is exactly why I run NoScript in my browser, but in order for your site to actually be usable, users are going to enable JavaScript and that's why a content security policy is important. You're also forgetting about the dangers of an attack vector via CDN (however unlikely this is, this is why hashes and cross-origin policies are used which you are missing for alpinejs). Either way, it takes very little effort to implement for huge benefit.

from rockylinux.org-hugo.

On a side note, these are the recommendations from the Fedora Infrastructure Application Security Policy. There's no harm in implementing these either.

from rockylinux.org-hugo.

What you did was hard-code it in the index.html file, but this article shows how you can generate it from Hugo. And a whitelist is going to involve hard-coding. It is a whitelist after all. I'm sure you can programmatically add to the whitelist but that's beyond the scope of this discussion.

Are you referring to the header? I'm not talking about hard-coding the CSP values, I'm talking about hardcoding the JavaScript data generated by Hugo.

Feel free to open a PR later and link this issue. I'm not against a CSP, I just think you misunderstood what I was talking about in terms of the inline JavaScript.

from rockylinux.org-hugo.

A hash for the inline JavaScript would be sufficient in this case, I would think, though.

from rockylinux.org-hugo.

I realize I didn't come across quite clearly. Basically we have Hugo generating some of the data in the inline JavaScript. Due to this, every time someone adds a new language to our site, the data changes. This will prevent us from creating a hash for the inline JavaScript without updating it for every PR. Does that make sense?

We're using StaticDeploy to deploy the site, so maybe @hbjydev can see if there's a better way to handle it on that side of things.

from rockylinux.org-hugo.

Really the only valid option would be to use a nonce at this point.

from rockylinux.org-hugo.

Well, I started improving the header inline, but I think I've hit a roadblock. Alpine.JS requires eval to function, and would force us to use "unsafe-eval".

from rockylinux.org-hugo.

For reference: theNewDynamic/thenewdynamic.com#110

from rockylinux.org-hugo.

From reading the issue linked in the aforementioned issue, it appears that they will implement measures in v3 to prevent issues with CSP, but for now we'll be forced to use 'unsafe-eval'.

from rockylinux.org-hugo.

I went ahead and implemented 3c8f349. Let me know if you have any suggested improvements. I think as long as we're using the nonce it should be fine. At least, much safer from attacks than otherwise not having it implemented.

from rockylinux.org-hugo.

For the inline JavaScript a few approaches come to mind:

1. Enforce changing the hash whenever adding a new language. Sure this is annoying, but no different than enforcing i.e linting changes. Since the hash will no longer match it will be immediately obvious when it breaks
2. Automate/script it somehow
3. Use Hugo Pipes to process the JavaScript. I'm not familiar with Hugo but this looks the most relevant

As for nonce vs hash, a nonce has to be regenerated on every HTTP request, it can't just be hard-coded like here. So we need to use a hash anyway unless you decide to add server-side CSP support.

from rockylinux.org-hugo.

I'm sorry, but I fail to see why we would need CSP support in this project. @remyabel Can you enlighten me here? It's a completely static site with no backend, so there's no risk in terms of data unless the end user has installed a virus that hacks its host through JavaScript files in a specific browser, which for everyone is extremely unlikely.

And plus, anything that we have to 'enforce' or do manually is strictly off the table. We're going to be using Weblate for our translations, so anything that requires us to manually add something prevents us from managing it in a sustainable way, which we desperately need to do given the scope of this and number of contributors.

If you can explain to me why we need CSP on a 100% static website, then I'll re-open this. But until then, I'm marking this as wontfix, because I fail to see why it's necessary.

from rockylinux.org-hugo.

It doesn't matter if it's a static website or not. It was already pointed out that alpinejs requires unsafe-eval which is an XSS vector. I also don't really consider the likelihood of a vulnerability to be that big of a factor. I lock my front door to keep people out no matter how unlikely it is that someone will break in.

Anyway, I understand that based on the reasoning you gave implementing this change will be painful so I'll concede.

from rockylinux.org-hugo.