[4.6] Separate xsrf handling and version checking

[epixa]

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.

[spalger]

Maybe we should mark this with a backwards compatibility comment of some sort, maybe we should do that in more places.

[spalger]

I think I would prefer that we implement this at the CLI, similarly to how we support legacy config values

[epixa]

Does the comment above it not suffice?

[ppisljar]

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]

@spalger Updated with your feedback from zoom

[spalger]

Would probably be easier to follow without all the !s

if (isUnsafeMethod && (missingVersionHeader || missingXsrfHeader)) {
  // ...
}

[epixa]

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 && missingXsrfHeader

I'd rather those negations be applied to boolean values rather than wrapping entire multi-condition statements like req.method === 'get' || req.method === 'head'

[spalger]

one typo, and one option for extra credit, but LGTM!

[epixa]

Fixed the typo and responded to the rest