[DISCUSS] Use script-src 'self' instead of script-src 'nonce-<base64-value>'

[kobelb]

The current default CSP rules use script-src 'unsafe-eval' 'nonce-<base64-value>'. This has proven problematic when using third-party dependencies which load their own scripts, requires plugin authors to add a nonce in certain situations and it's now proving problematic for the new platform to support dynamic imports.

I was recently reading through the white-paper which was the impetus for the introduction of the concept of a nonce to determine the original problem that they were trying to solve, to determine whether it'd be appropriate for us to switch to script-src 'self' or whether we'd be abandoning the benefits of the nonce. Based on my understanding of the paper, the concept of a nonce was added because a large number of CSP policies ended up white-listing unsafe endpoints which allowed attackers to perform a XSS. This would not be an issue if we were to switch to script-src 'self' as we would only be allowed to load scripts from Kibana itself, which is a secure endpoint.

I'm unable to think of any other reason which would prevent us from switching to script-src 'self', but I'd like to hear from others before making this decision.

[elasticmachine]

Pinging @elastic/kibana-security

[kobelb]

/cc @epixa

[joshdover]

Using the nonce directive in our CSP policy adds friction to adding dynamic import support to New Platform plugins. Dynamic imports are considered a necessity for NP plugins due the fact that all NP plugins will run in the browser at once, and not being able to use dynamic imports will make these bundles grow very large.

When a NP plugin tries to use a dynamic import, Webpack does not attach the nonce directive to the <script> tag. This happens because:

• Webpack requires the entry point file to assign the nonce to the global __webpack_nonce__ variable in order to enable the nonce feature of dynamic imports.
• New Platform plugins are each built as separate Webpack entry points
• Webpack code running in the plugins do not have access to the __webpack_nonce__ variable assigned in the Core bundle, because they are separate entry points.

This can be worked around by adding the __window_nonce__ = window.__kbnNonce__; to the plugin's entry point. However, this requirement creates an implicit API between Kibana and 3rd party plugins in order to function. Plugins should be able to load additional bundles without this requirement so we do not have to bind them to our specific tooling.

Additionally, it seems dangerous to expose our CSP nonce as a global variable. I could be wrong, but it seems malicious code could use this nonce to load untrusted scripts from external sources with this knowledge.

Moving to 'self' would solve this problem completely by allowing any scripts from the Kibana server to be loaded.

[kobelb]

Additionally, it seems dangerous to expose our CSP nonce as a global variable. I could be wrong, but it seems malicious code could use this nonce to load untrusted scripts from external sources with this knowledge.

This was briefly discussed with the original implementation of CSP. Even if we didn't expose the CSP nonce as a global variable, already running JavaScript is able to query the DOM to find a script tag with an existing nonce attribute and read it's value. It's rather awkward, but if malicious JavaScript is already running being able to load another malicious javascript file vs. just execute the malicious action itself is negligible.

[epixa]

From a security perspective, I think the difference between self and nonce is subtle. If you're serving Kibana on a dedicated host/port, then they should provide similar security. If you're serving Kibana behind its own sub path on a shared host/port, then self could load insecure scripts if it's possible to upload/serve them from that host (perhaps in a shared user environment).

I think this is more of an exercise of theory than of practice though. If nonce is continuing to cause us problems, and especially if nonce is actively making it hard to adopt more secure policies elsewhere (like the maps worker thing), then we should switch to self.

We have to carefully consider BWC ramifications of doing this in 7.x. I'm not sure we should rule it out, but we should understand the ramifications.

[kobelb]

If you're serving Kibana on a dedicated host/port, then they should provide similar security. If you're serving Kibana behind its own sub path on a shared host/port, then self could load insecure scripts if it's possible to upload/serve them from that host (perhaps in a shared user environment).

That's a good point I hadn't thought of. Theoretically, we could instruct administrators to customize their csp rules to specify a host including the sub-paths in these situations. This isn't likely something we'd want to do automatically though, as Kibana is commonly behind a reverse-proxy or load balancer and getting users to configure the "public facing URL" of Kibana has proven problematic for both Reporting and SAML.

We have to carefully consider BWC ramifications of doing this in 7.x. I'm not sure we should rule it out, but we should understand the ramifications.

Are there any BWC ramifications that you're thinking of? The only ones that come to mind are third-party plugins which are currently using the nonce based approach to access resources from other origins. Ideally, we'd be able to support both nonce and self, but I believe we ran into issues when trying to do so previously: #29545 (comment)

[epixa]

@kobelb If people modified their csp.rules to add to the defaults, they'll have {nonce} in their kibana.yml. If we roll out changes to Kibana that break when nonce is set (like pretty much everything with new platform and async imports), then we'll effectively brick their install. We'd probably want to remove the nonce behavior entirely rather than simply removing it from the defaults, in which case we'd probably need to parse that out of the csp.rules if it is set. We probably should log a deprecation notice if {nonce} is set too.

[kobelb]

@kobelb If people modified their csp.rules to add to the defaults, they'll have {nonce} in their kibana.yml. If we roll out changes to Kibana that break when nonce is set (like pretty much everything with new platform and async imports), then we'll effectively brick their install. We'd probably want to remove the nonce behavior entirely rather than simply removing it from the defaults, in which case we'd probably need to parse that out of the csp.rules if it is set. We probably should log a deprecation notice if {nonce} is set too.

Good call. In a similar vein, we'd likely want to force add the 'self' rule to prevent users from bricking their install if it's not specified.

[joshdover]

@kobelb I can implement this if needed, just let me know.

[kobelb]

@joshdover if you're offering, and there are no other objections, by all means!