-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Client-side unsafe-eval Sandbox #27047
Comments
Pinging @elastic/kibana-security |
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. |
@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. |
Our OWASP ZAP scan now complains about |
Hey @pburkholder, if OWASP ZAP is complaining specifically about the |
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.. |
@hjmwijnen this is the only viable initiative we've identified so far. You're right that simply removing the script-src A precursor to this is to first audit the locations where |
@legrego Have you tried to replace the 'unsafe-eval' value from either hash or nonce in the script-src directive? |
@m-tomar thanks for the suggestion. It's unfortunately not that simple. All of the code that we write directly does not require
Using |
Through the work done in #124484 (thanks @watson!), and several other PRs, we no longer believe that a client-side There is a related issue open to allow plugins to run arbitrary code within a trusted inline script. Follow along here: #132595 |
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 aWebWorker
. Aniframe
with thesandbox
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.
The text was updated successfully, but these errors were encountered: