Allow for cookie's SameSite attribute to be configurable

[legrego]

Currently, Kibana does not set the SameSite attribute on its session cookie. Up until recently, this was tolerable, but Chrome recently (version 80) updated its default configuration to treat unset SameSite attributes to mean Lax (https://www.chromestatus.com/feature/5088147346030592).

This is problematic for users who embed Kibana in an iframe. We should allow the SameSite setting to be configurable via kibana.yml, so users can choose if they want Strict, Lax, or None.

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[pgayvallet]

Seing hapijs/hapi#3987,

Unfortunately this breaks some not that old browsers including Safari 12 and Chrome 67, so I suspect it needs to be set or not based on the User-Agent header of the request

it seems we will need to only set this header when the user's browser supports it?

[legrego]

Seing hapijs/hapi#3987,

Unfortunately this breaks some not that old browsers including Safari 12 and Chrome 67, so I suspect it needs to be set or not based on the User-Agent header of the request

it seems we will need to only set this header when the user's browser supports it?

That depends. According to our support matrix, we only support the latest GA version of each browser listed. We support both Chrome and Safari, but both of their latest versions appear to support SameSite=None.

If this was a configurable value (defaulting to unset like today), then users can opt-in to a different behavior if they wish to, but at that point, it's up to each user to decide how they want to configure their cookies.

I think we should discuss changing our default to Lax in the future - perhaps as a breaking change in 8.0.

[patodevilla]

Is there a solution for kibana on elastic cloud?

[rowan-m]

You may want to consider backporting or documenting some kind of proxy solution for existing users. This change is currently rolling out in Chrome stable which will mean any of your users with a cross-site iframe embed for their dashboard will not be able to access it.

[SpencerTranter]

This definitely threw us through a loop. Would be great to have some proxy documentation to get around this for new Kibana developers :)

[mshustov]

You may want to consider backporting or documenting some kind of proxy solution for existing users.

@legrego Does the Security team have the capacity to work on documentation?

That depends. According to our support matrix, we only support the latest GA version of each browser listed. We support both Chrome and Safari, but both of their latest versions appear to support SameSite=None.

@joshdover What is the earliest release we can work on this? I suppose v7.9, providing we document a workaround with proxy.

[joshdover]

@joshdover What is the earliest release we can work on this? I suppose v7.9, providing we document a workaround with proxy.

Yeah 7.8 is pretty full for us. Do we have an idea of how difficult of a fix this is?

[joshdover]

We've decided to go ahead and fix this and maybe make it configurable (opt-in) to ensure we don't break older browser support (esp. IE11).

We will backport this to 7.7 with @LeeDr's blessing.

[mshustov]

can be postponed by 7.8-7.9 https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html

[sergibondarenko]

@restrry @joshdover

We should allow the SameSite setting to be configurable via kibana.yml, so users can choose if they want Strict, Lax, or None

If you provide a service that other sites consume such as widgets, embedded content, affiliate programs, advertising, or sign-in across multiple sites then you should use None to ensure your intent is clear.

To make Kibana work in an iframe on a 3rd party website we will need to set cookies like this Set-Cookie: key=value; SameSite=None; Secure. Kibana is still using hapi v17 webserver to run itself on a host. And hapi introduced support for SameSite=None in v19.0.0. Here is the related commit to the hapi state plugin. Thus hapi server must be upgraded in order to use SameSite=None.

[kobelb]

Is the current plan to introduce a setting to configure the SameSite attribute, but default it to being unset?

[legrego]

Is the current plan to introduce a setting to configure the SameSite attribute, but default it to being unset?

We can, but without the Hapi upgrade, I don't think it'll solve the embeddable problem with Chrome, as it doesn't appear we can set the value to None unless we manage to patch our version of Hapi to add support for this.

My understanding is that the Hapi upgrade is at least soft-blocked on removal of the Legacy Platform. @watson experimented with an upgrade to 18.4.1 in #61959, but put it on hold due to complications with legacy plugins. The subsequent move from 18 to 19 (or just straight to 19) has an unknown level of effort at this point.

[mshustov]

We can, but without the Hapi upgrade, I don't think it'll solve the embeddable problem with Chrome,

There a couple of options:

• to patch existing Hapi version. For example, there was a workaround for v18. We can make it work for v17 as well Support SameSite=None for cookies hapijs/hapi#3987 (comment)
• to update the Hapi version. There are just a few plugins with the server-side left. I can take a look at Upgrade hapi to @hapi/hapi 18.4.1 #61959 If I can timebox the version update ~2 days, I'd go this way.

As a note: Chrome resumed the Same Site cookie changes in July. It means we must fix the issue in 7.9 and it cannot wait for the plugins to finish migration (#56205 targeted v7.10) https://blog.chromium.org/2020/05/resuming-samesite-cookie-changes-in-july.html

[mshustov]

The solution depends on how deep we are going to backport the fix. Hapi version update we can backport to v7.7 at best.

[dminovski0]

To allow third-party cookies in iFrame, add the parameter xpack.security.sameSiteCookies: None in kibana.yml with ELK stack version above 7.8.0. It can also be used in the elastic.co cloud provider.
References: https://discuss.elastic.co/t/cookies-issue-while-embedding-kibana-dashboard-with-iframe/256777/8

[gaetano603]

Is there any way to set SameSite = 'None' in Kibana version 7.6.2?
In http_tools.js there is the variable isSameSite but it is not possible to set it to 'None'.
My goal is to authenticate from a different domain bypassing the login page.

[dminovski0]

@gaetano603 In some of the newer versions, adding the following parameters in kibana.yml does the same thing:
xpack.security.secureCookies: true
xpack.security.sameSiteCookies: None

[gaetano603]

I tried but it fails because SameSite is not allowed.
This why I'm using Kibana 7.6.2 version.

[mshustov]

@gaetano603 I'm afraid you have to upgrade. It's supported starting from v7.8.1.

[gaetano603]

@restrry hence, if I don't set the SameSite attribute to None, isn't there another way to authenticate to kibana skipping login page executing an HTTP POST call to login endpoint(internal/security/login)?

[mshustov]

@gaetano603 This is a question that I think is better suited to the Kibana discuss forum or contacting our support team. We reserve Github for bugs and feature requests: https://discuss.elastic.co/c/elastic-stack/kibana/7

[dminovski0]

@gaetano603 Executing an HTTP POST call to that endpoint will return a cookie that can be used for login. The JSON object that needs to be sent is shown in this post: https://discuss.elastic.co/t/kibana-7-10-login-issues/255201/3. But, this needs to happen before the user sees the page.

[gaetano603]

I thought the problem might be that CORS are not enabled.
I modified the http_tools.js file to enable CORS like this.
cors: { additionalHeaders: ['kbn-version','kbn-xsrf','cookie'], origin: ['*'], credentials: true },
instead of cors: config.cors.
Do I need to add anything else to enable CORS?
I remember that I am in version 7.6.2

[gaetano603]

Hi, I upgraded Kibana to version 7.10.2 as you suggested.
I added in kibana.yml
xpack.security.secureCookies: true
xpack.security.sameSiteCookies: None
for the SameSite setup, but when I try to access the login page I get this result.

While on the Cookie section I get this warning:
This Set-Cookie was blocked because it had the "Secure" attribute but was not received over a secure connection.

What changes do I have to make to establish a "secure" connection?

[mshustov]

@gaetano603 you need to access the server over HTTPS connection

[bluefangs]

Would having an nginx reverse proxy handling the https do?

[mshustov]

Would having an nginx reverse proxy handling the https do?

I believe so.

[bluefangs]

A quick follow up question. How would I need to define this if i were to add the env vars via docker-compose?

XPACK_SECURITY_SECURE_COOKIES=true
XPACK_SECURITY_SAME_SITE_COOKIES=None

Would this be correct?

Update

This worked.

XPACK_SECURITY_SECURECOOKIES=true
XPACK_SECURITY_SAMESITECOOKIES=None