[4.6] Separate xsrf handling and version checking #8152
Conversation
| const versionCheckDisabled = config.get('server.disableVersionCheck'); | ||
| const xsrfProtectionDisabled = config.get('server.xsrf.disableProtection'); | ||
| // this accepts the xsrf config strictly for legacy reasons | ||
| const disabled = versionCheckDisabled || xsrfProtectionDisabled; |
There was a problem hiding this comment.
Maybe we should mark this with a backwards compatibility comment of some sort, maybe we should do that in more places.
There was a problem hiding this comment.
I think I would prefer that we implement this at the CLI, similarly to how we support legacy config values
There was a problem hiding this comment.
Does the comment above it not suffice?
|
LGTM, makes complete sense to check for both version and the new header to maintain backward compatibility and the comment above the disabled definition makes it clear enough in my opinion. |
epixa
force-pushed
the
4.6-headercheck
branch
from
98c806f to
00f9365
Compare
|
@spalger Updated with your feedback from zoom |
| expected: version, | ||
| got: submission | ||
| })); | ||
| if (!isSafeMethod && !hasVersionHeader && !hasXsrfHeader) { |
There was a problem hiding this comment.
Would probably be easier to follow without all the !s
if (isUnsafeMethod && (missingVersionHeader || missingXsrfHeader)) {
// ...
}There was a problem hiding this comment.
The logic here is intentionally that both headers must be missing in order to error. So really it's a question of:
!isSafeMethod && !hasVersionHeader && !hasXsrfHeader
// or
isUnsafeMethod && missingVersionHeader && missingXsrfHeaderI'd rather those negations be applied to boolean values rather than wrapping entire multi-condition statements like req.method === 'get' || req.method === 'head'
|
one typo, and one option for extra credit, but LGTM! |
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.
epixa
force-pushed
the
4.6-headercheck
branch
from
00f9365 to
4054711
Compare
|
Fixed the typo and responded to the rest |
Backport of #8151
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.