[HTTP] No default-src fallback specified for CSP

[jloleysens]

Without a default value for default-src certain other directives like connect-src will currently fallback to "allow all" (today's default). This can lead to a regression because adding the following config:

csp.connect_src:
  - "my.cool.thing"

Will actually result in the following CSP:

connect-src 'self' my.cool.thing

This is far stricter than the original "allow anything" and can lead to, for example, telemetry endpoints not being reachable using JS APIs like fetch when calling telemetry-thingy.elastic.co.

We could approach this in a few ways:

1. We try to make overal CSP stricter by setting something default-src: 'none', will require an audit to make sure we aren't breaking something (almost definitely will break something), this does not seem desirable
2. We accept that setting csp.* requires additional config to allow things like telemetry to work (also not very desirable imo)
3. We can let applications/plugins that need to call external routes register the external endpoints they need to talk to at setup time, probably the most complete/best approach. We can leave default-src untouched in this case so that we don't kick up the work in the first approach.
4. ...something else?

Tasks

Preview Give feedback

1. Outline what we want to do, for each distribution type
2. Which directives need to be populated before we set default-src? (img-src for example)

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[jloleysens]

Regardless, I think we should probably add data: to img-src since there are many instances of base64d images being loaded in Kibana

kibana/packages/core/http/core-http-server-internal/src/csp/csp_directives.ts

Line 42 in 623177f

'img-src': [`'self'`],

WDYT?

[jeramysoucy]

Thanks @jloleysens! I like the idea of having plugins register known external sources/endpoints, but don't have a clear idea of how daunting of an ask that might be to some teams, or if it's always feasible (e.g. if there might be some end user config to consider in some cases). I'll bring this up with the team to discuss at our next sync. I see this is referenced from a couple of other items - how urgent would you say this is?

[jloleysens]

how daunting of an ask that might be to some teams, or if it's always feasible (e.g. if there might be some end user config to consider in some cases)

I fully agree re scope. It'd be great to learn of other possible approaches, these were just my first 3 ideas. Ideally we can find something more incremental, as registering a value will currently get us into the more strict CSP that led to this issue.

The biggest benefit of plugin owners registering endpoints is that they have all the context about where a link is coming from and how it is set (e.g. via kibana.yml, hardcoded etc) and can add test code to back it up.

how urgent would you say this is?

Overall not high urgency :) . I don't think this is blocking anything. I also don't know how many on-prem/cloud are running into this. Only known issue is blocking Telemetry on serverless. Also, this is old code so I'm guessing it's not causing wide-spread problems. For our purposes the workaround is to just set CSP accordingly in kibana.yml.

[jsanz]

@jloleysens The Kibana Maps app allows users to load external layers not served by Elasticsearch or Elastic Maps Service. If I understand this correctly, the proposed change would prevent users from loading any layers unless they are white-listed by their Kibana admins, right?

I've created a public minimal dashboard in our cloud that loads a Web Map Service layer as an example of this feature so you can check the external requests in a production environment.

@elastic/kibana-presentation

[jloleysens]

@jsanz I guess that is one possibility. We could also choose to keep connect-src relatively open and document how that piece of config interacts with features like maps.

I'd say this issue is more about figuring out if we want to get to a place that is more strict CSP overall. Such that adding a piece config:

csp.font_src:
  - "my.cool.thing"

Allows Kibana to work as it should while allowing additional domains to be reached. Right now adding this config results in a much stricter CSP which is not what I was expecting -- and why chose to classify this as a bug... Perhaps my expectation was wrong though!