Client-side unsafe-eval Sandbox

[kobelb]

With the effort to enable CSP, the end-goal is to be able to remove the ability to perform unsafe-eval. However, there's certain functionality which is dependent on this language feature, so we'll want to provide a Sandbox for this code to execute in, that will be run in a separate VM than then rest of Kibana. The input/output to the sandbox will have to be treated as potentially unsafe and handled appropriately, but the execution of this unsafe code will then be unable to affect the rest of Kibana.

There are two obvious mechanisms for enabling this client-side: an iframe and a WebWorker. An iframe with the sandbox attribute, coupled with custom CSP rules, affords us a lot of flexibility but it generally runs within the same context as the main thread of the "host" page, so this leaves us open to CPU based DoS attacks. Based on the usages of the sandbox, this is potentially an acceptable limitation.

WebWorkers share the same origin as the page which spawned the WebWorker, so while providing the benefit of running in a separate thread, they introduce additional complexity when it comes to restricting their behavior to not abuse the inherent behaviors of the same origin restrictions.

[elasticmachine]

Pinging @elastic/kibana-security

[epixa]

Is this even practical to do? I mean, things like angular template compilation are the reason require unsafe-eval, and I'm not sure how we'd offload that particular function in angular to a sandbox.

[kobelb]

@epixa it's not a silver bullet, and I agree that using this sandbox likely isn't what we'd want to do for AngularJS. However, there are other libraries within Kibana that could benefit from this sandbox. Before moving code to run within this sandbox, I think we should explore any other available options, as it comes with additional complexity from a technical and performance standpoint.

[pburkholder]

Our OWASP ZAP scan now complains about CSP: style-src unsafe-inline so I think this is closest related issue. If there's work underway (or a fix) elsewhere, let me know. Otherwise, it looks like I'll have to note monthly that this is an upstream vendor issue that we can't resolve ourselves. Thanks, Peter

[kobelb]

Hey @pburkholder, if OWASP ZAP is complaining specifically about the style-src CSP attribute, this would be a different issue than what is described here. Removing style-src unsafe-inline will be a separate effort, and #54984 (comment) has some of the reasoning for why we haven't done so yet.

[hjmwijnen]

Are there any (other) initiatives to remove the script-src 'unsafe-eval' from the CSP header already? Our internal security audit team is asking questions about whether this part can be removed from the header. Obviously that won't work..

[legrego]

@hjmwijnen this is the only viable initiative we've identified so far. You're right that simply removing the script-src unsafe-eval won't work. Kibana has dependencies which rely on this functionality.

A precursor to this is to first audit the locations where unsafe-eval is currently required, so that we can decide the best path forward to removing or sandboxing their execution: #36311

[m-tomar]

@legrego Have you tried to replace the 'unsafe-eval' value from either hash or nonce in the script-src directive?

[legrego]

@m-tomar thanks for the suggestion. It's unfortunately not that simple. All of the code that we write directly does not require unsafe-eval. Rather, some dependencies that Kibana pulls in use unsafe-eval internally. Examples of such dependencies include (but are not limited to):

• Handlebars (when compiling templates)
• Vega (when interpreting its visualization syntax)
• Lodash (via the _.template function)

Using hash or nonce won't fix the unsafe code that lives within our dependencies. We either have to submit fixes to the dependencies themselves, or stop using those problematic features altogether. We've started this effort in #94626, but it's a rather large undertaking for a project as large as Kibana.

[legrego]

Through the work done in #124484 (thanks @watson!), and several other PRs, we no longer believe that a client-side unsafe-eval sandbox is necessary. We will re-open this issue if we learn otherwise.

---

There is a related issue open to allow plugins to run arbitrary code within a trusted inline script. Follow along here: #132595