Kibana: [CSP] only test CSP on first request

Created on 28 May 2019  路  9Comments  路  Source: elastic/kibana

Could there be a way to cache the CSP-support of a browser in localStorage or something so that the CSP error that is described in the dev console doesn't confuse people once they reload the page? I've seen many people try to blame behaviors they're seeing on the CSP error (even with the "expected" log line that follows it) and think a cache value in localStorage would be sufficient for caching the CSP support level...

cc @epixa

CSP Security enhancement
Source
picture spalger
👍1

Most helpful comment

What if we only used the local storage cache if csp.strict is disabled?

We could do that, but there are two problems:

  1. It would be pretty complicated since we'd need to parse the injected metadata a lot earlier, before we even load any of the JavaScript bundles. The way it is implemented today is that we always do an extremely lightweight check that just sets a global flag, and then the business logic of core just reacts to the flag as if it were just some environmental config. We'd need to not perform the check at all based on injected metadata though.
  2. It's an inconsistent behavior, with the desirable behavior only happening on our least desirable configuration (no csp strict). It is the default behavior now, but come 8.0 the default behavior will revert back to spamming the log. It seems like if we're going to live with this, we might as well live with it.

That's going to be the default soonish anyway isn't it?

csp.strict is disabled by default now. It will be _enabled_ by default in 8.0.

picture epixa on 11 Jul 2019
👍2

All 9 comments

Pinging @elastic/kibana-platform

elasticmachine picture elasticmachine on 28 May 2019

That's a great idea.

epixa picture epixa on 28 May 2019

Pinging @elastic/kibana-security

elasticmachine picture elasticmachine on 11 Jul 2019

After giving this some thought, I have concerns about doing this. Both cookies and localStorage can be modified by end users, so this would give a user the ability to circumvent the CSP check. This isn't really a problem with csp.strict disabled since it would only impact the appearance of a warning message, but I think it's important that administrators can rely on csp.strict to actually block users on deficient browsers.

epixa picture epixa on 11 Jul 2019
👍1

What if we only used the local storage cache if csp.strict is disabled?

kobelb picture kobelb on 11 Jul 2019

That's going to be the default soonish anyway isn't it?

spalger picture spalger on 11 Jul 2019

What if we only used the local storage cache if csp.strict is disabled?

We could do that, but there are two problems:

  1. It would be pretty complicated since we'd need to parse the injected metadata a lot earlier, before we even load any of the JavaScript bundles. The way it is implemented today is that we always do an extremely lightweight check that just sets a global flag, and then the business logic of core just reacts to the flag as if it were just some environmental config. We'd need to not perform the check at all based on injected metadata though.
  2. It's an inconsistent behavior, with the desirable behavior only happening on our least desirable configuration (no csp strict). It is the default behavior now, but come 8.0 the default behavior will revert back to spamming the log. It seems like if we're going to live with this, we might as well live with it.

That's going to be the default soonish anyway isn't it?

csp.strict is disabled by default now. It will be _enabled_ by default in 8.0.

epixa picture epixa on 11 Jul 2019
👍2

Any opposition to close this issue given the recent discussion?

kobelb picture kobelb on 15 Jul 2019

No objection from me

epixa picture epixa on 22 Jul 2019
Was this page helpful?
0 / 5 - 0 ratings

Related issues

ctindel picture ctindel  路  3Comments
bhavyarm picture bhavyarm  路  3Comments
stacey-gammon picture stacey-gammon  路  3Comments
spalger picture spalger  路  3Comments
timroes picture timroes  路  3Comments