Kibana: Headers in Response should be customizable - Information Leakage Through Http Headers (CWE-200)

[kiju98]

Describe the feature:
There is a concern about "Information Leakage Through Http Headers (CWE-200)" about Kibana. The details is as follows:

Kibana URL returns the following as part of the header:

kbn-name: kibana 
kbn-version: 5.6.0 
kbn-xpack-sig: a042e166e84a1ae82e586cc3602cfdec 

This may give potential attackers the information about the application and version running on that port. You can find more detail about the concern below:

• Information Leakage Through Http Headers (CWE-200): Webserver version could be obtained from http response header
• Web server's version and development framework information were disclosed in a HTTP response header.
• The vulnerability allow an attacker to gain information about web server and technology being used for the application. These information are the essential information for an attacker to perform further attack against the server and the application
• Recommendation: Informative banner such as header containing name and version of the server or the development framework should be removed by adjusting the configuration

We can enable SSL to encrypt all headers but wouldn't it be great if Kibana can either (i) customize these headers (e.g. set kbn-version displayed in header as N/A) or (ii) remove them from the header response ?

[epixa]

While they do occasionally get flagged by scanners, we don't consider these headers to be an additional security risk in practice.

The Kibana UI is a client-side application, which means there is a large amount of JavaScript that gets served directly to every user's browser. If a person was curious what project was being used, they wouldn't need the kbn-name header, they could just open up the raw HTML or JavaScript and see a bunch of references to Kibana itself. This sort of security concern is probably more applicable to backend APIs rather than projects that serve a client-side UI as well, though even in those situations it's dubious because there are other ways to learn what sort of software is being used to power any given service.

The kbn-xpack-sig doesn't expose anything sensitive. The value of this header is a unique hash of non-sensitive information that includes license type that the client-side app uses to determine if the xpack license has changed on the backend so it can update the UI accordingly. You can't learn anything useful from the value itself, as the only use it has is to indicate when something has changed, and at that point you must be able to send a valid and authenticated request to the backend in order to figure out what the change actually was.

The kbn-version header does expose the Kibana version, but this also doesn't increase the security risk in practice. In the years it has existed, we've disclosed about 20 vulnerabilities in Kibana through our responsible disclosure policy alongside the versions that fixed each of them. If a user was interested in attacking a Kibana app, there are a small enough amount of vulnerabilities where they could reasonably just attempt each one until they found one that sticks. Starting from the middle of the pack, this would mean in the best case scenario, the user would need to attempt only 10 attacks before it discovered a possible vector on a vulnerable install.

Security through obscurity is no security at all, and we're not interested in supporting it just for the sake of appeasing automated scanners. The best way to keep your Kibana install secure is to keep it up to date with the latest maintained versions, and if you are on an older insecure version and an attacker was targeting you, removing these headers won't protect you.