CSP unsafe-eval auditing #36311
Labels
blocked
enhancement
New value added to drive a business result
Feature:Hardening
Harding of Kibana from a security perspective
Feature:Security/CSP
Platform Security - Content Security Policy
impact:low
Addressing this issue will have a low level of impact on the quality/strength of our product.
loe:small
Small Level of Effort
Team:Security
Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Comments
kobelb
added
Team:Security
|
Pinging @elastic/kibana-security |
|
There's a bug in Chrome 72+ where unsafe usages of |
|
Looks like the chromium bug has been fixed, but I haven't verified the fix locally yet |
exalate-issue-sync
bot
added
impact:low
22 tasks
watson
pushed a commit
that referenced
this issue
May 23, 2022
…#124484) Adds a new experimental Kibana setting called `csp.disableUnsafeEval` which will default to `false`. When set to `true`, it will remove `unsafe-eval` from our CSP. Also introduces a new module called `@kbn/handlebars` which is a replacement for the official `handlebars` module used in the frontend. This new module is necessary in order to avoid calling `eval`/`new Function` from within `handlebars` which is not allowed once `unsafe-eval` is removed from our CSP. The `@kbn/handlebars` module is simply an extension of the main `handlebars` module which adds a new compile function called `compileAST` (as an alternative to the regular `compile` function). This new function will not use code-generation from strings to compile the template but will instead generate an AST and return a render function with the same API as the function returned by the regular `compile` function. This is a little bit slower method, but since this is only meant to be used client-side, the slowdown should not be an issue. The following limitations exists when using `@kbn/handlebars`: The Inline partials handlebars template feature is not supported. Only the following compile options will be supported: - `knownHelpers` - `knownHelpersOnly` - `strict` - `assumeObjects` - `noEscape` - `data` Only the following runtime options will be supported: - `helpers` - `blockParams` - `data` Closes #36311
j-bennet
pushed a commit
to j-bennet/kibana
that referenced
this issue
Jun 2, 2022
…elastic#124484) Adds a new experimental Kibana setting called `csp.disableUnsafeEval` which will default to `false`. When set to `true`, it will remove `unsafe-eval` from our CSP. Also introduces a new module called `@kbn/handlebars` which is a replacement for the official `handlebars` module used in the frontend. This new module is necessary in order to avoid calling `eval`/`new Function` from within `handlebars` which is not allowed once `unsafe-eval` is removed from our CSP. The `@kbn/handlebars` module is simply an extension of the main `handlebars` module which adds a new compile function called `compileAST` (as an alternative to the regular `compile` function). This new function will not use code-generation from strings to compile the template but will instead generate an AST and return a render function with the same API as the function returned by the regular `compile` function. This is a little bit slower method, but since this is only meant to be used client-side, the slowdown should not be an issue. The following limitations exists when using `@kbn/handlebars`: The Inline partials handlebars template feature is not supported. Only the following compile options will be supported: - `knownHelpers` - `knownHelpersOnly` - `strict` - `assumeObjects` - `noEscape` - `data` Only the following runtime options will be supported: - `helpers` - `blockParams` - `data` Closes elastic#36311
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The goal of CSP is to get rid of the usages of "unsafe eval". As a step toward this, we should investigate using
report-uri/report-to/Content-Security-Policy-Report-Onlyto prevent new violations and help us determine the usages of "unsafe eval" we should be working toward removing.Ideally, this would run as part of CI for the functional UI tests and fail CI if we find new usages which aren't already known. This will let us work toward removing all existing usages without continuing to add new usages which later have to be addressed. We could also potentially use this same approach as part of dev mode to catch violations which aren't covered by the functional ui tests.
Blocked by #40097 and
https://bugs.chromium.org/p/chromium/issues/detail?id=925638The text was updated successfully, but these errors were encountered: