Separate xsrf handling and version checking#8151
Conversation
|
jenkins, test this |
|
seems tests on master are broken. otherwise it LGTM |
|
I need to do some changes to this, but I figured I'd get the 4.6 stuff done first: #8152 |
|
I marked this as a blocker since it went into 4.6 already. |
src/server/http/version_check.js
Outdated
There was a problem hiding this comment.
Do we really need this? I realize previously we had conflated version checking and xsrf, but we always exposed it as an xsrf check. The version check is new, and users could legitimately want to skip xsfr check, but not the version check. This prevents them from choosing one or the other.
There was a problem hiding this comment.
Yeah, don't review this PR right now. The 4.6 PR changed a bunch of this and was merged this morning: #8152
I'll forward port those changes to this PR before we review again.
|
@epixa you're still planning to update this PR, right? |
|
Yep, once 4.6.1 goes out. |
Traditionally we've relied on the kbn-version header for csrf protection, but that is also used for the client-side Kibana version check that alerts users when their client is out of date and needs to be refreshed, so it must match the version of Kibana exactly. This poses a problem for any programmatic access that would only get set up once but may run repeatedly throughout the future (e.g. watcher), so there's now the additional option of specifying the kbn-xsrf header instead. The value of the header does not matter, but its very presence is all that is necessary to avoid xsrf attacks. The xsrf protection just needs either one of these headers to exist.
|
@w33ble This is good to go |
|
LGTM |
Separate xsrf handling and version checking Former-commit-id: ec3abde
4 participants
Traditionally we've relied on the kbn-version header for csrf
protection, but that is also used for the client-side Kibana version
check that alerts users when their client is out of date and needs to be
refreshed, so it must match the version of Kibana exactly.
This poses a problem for any programmatic access that would only get set
up once but may run repeatedly throughout the future (e.g. watcher), so
there's now the additional option of specifying the kbn-xsrf header
instead. The value of the header does not matter, but its very presence
is all that is necessary to avoid xsrf attacks.
The xsrf protection just needs either one of these headers to exist.
Forward port of #8152