Implement Content Security Policy

[sandstrom]

Kibana is an excellent tool for log data (via Logstash). Log data is raw (it should be), but this also increases the vulnerability to XSS. Perhaps it would be a good idea to harden Kibana with CSP.

https://developer.mozilla.org/en-US/docs/Web/Security/CSP
http://www.html5rocks.com/en/tutorials/security/content-security-policy/

[epixa]

I think we should target this for CSP (on newlines for readability):

default-src 'self'         // also covers script-src and connect-src in addition to others
connect-src <configurable> // see below
object-src 'none'
base-uri 'self'            // this could be 'none' since we don't use it, but we've said we want to use it
form-action 'none'         // blocked on server by csrf anyway
sandbox allow-scripts      // allows js, but not eval and not inline

connect-src locks down requests such as xhr to a specific set of hosts, but it is very common for people to want to make certain requests across domains, so this really needs to be something can be configured at least by plugins if not through kibana.yml. Out of the box, we should use self though.

I think the only inline script we use right now is the bootstrapping code in the initial payload, but #15904 should remove that need.

Unfortunately, I think we'll unsafe-eval on sandbox for the time being because angular does some controlled eval stuff in its rendering/digest code. We should verify the extent of this and then aggressively get rid of all usage of it though so we can remove this as soon as possible.

[thomasneirynck]

I think we should keep unsafe-eval. Disallowing it prevents us to use other libraries as well. An example is Vega. The library ensures input expressions are parsed safely, but uses eval to generate executable javascript.

A blanket block of eval is a course method to ensure security. Rather, I would like us to evaluate the impact of script-injection attacks on a library-2-library basis, instead of enforcing it by a CSP, particularly as it pertains to unsafe-eval.

[sandstrom]

Ideally the CSP lockdown should be as tight as possible.

One alternative (in case a tight lockdown is impossible) is to use the newer strict-dynamic keyword. It basically establishes a 'chain of trust', where blessed script tags (via nonce or hash), and any subsequent scripts these scripts may load, are allowed to execute. With strict-dynamic the 'unsafeness' of unsafe-eval is much less of a problem.

More details:
https://csp.withgoogle.com/docs/strict-csp.html

[nyurik]

I did a sample code with a very restrictive CSP rule set for the main window, and a much more relaxed (anything goes) rules for the iframe content in this test: https://github.com/nyurik/csp-vega-test . Note that the <iframe srcdoc="..."> attribute would not work because in that case CSP rules are still applied to iframe's content. It only works with the src="...". Kibana server should provide a sandbox-oriented downloads (e.g. just the Vega libraries bundle and some simple HTML for the iframe content). Who would be the best person to talk to about changes to Kibana core for this?

[epixa]

Our initial CSP implementation was merged in #29545, so I'm going to close this, and we can track any future changes to this policy as discrete issues.

[nyurik]

Just FYI -- Vega 5.13.0 adds a slower CSP-compliant interpreter version in case we ever get to the point of a full CSP lock down.