39

It was not until recently that I began to question the use for the Server field in the HTTP Response-Header.

I did some research:

RFC 2616 states:

14.38 Server

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.

   Server         = "Server" ":" 1*( product | comment )

Example:

   Server: CERN/3.0 libwww/2.17

If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. Instead, it SHOULD include a Via field (as described in section 14.45).

  Note: Revealing the specific software version of the server might
  allow the server machine to become more vulnerable to attacks
  against software that is known to contain security holes. Server
  implementors are encouraged to make this field a configurable

This, however, makes no mention of the purpose of this field. This seems like information disclosure to me. These server strings give away a lot of information that is great for anyone trying to fingerprint the server. Automated scanning tools would quickly identify unpatched or vulnerable servers. Having my web server present version information for itself and modules like OpenSSL seems like a bad idea.

  • Is this field needed... for anything? If so, what?
  • Is it already best practice / common place to disable or change this field on servers?

I would think that, from a security perspective, we would want to give the enemy (ie: Everyone) as little information as possible while still allowing business to continue. Here is an interesting write-up on information warfare.

ZnArK
  • 607
  • 1
  • 6
  • 10

2 Answers2

28

Server information should be removed from HTTP responses, and its an insecure default to leak this data. This isn't a major security risk, or even a medium security risk - but I don't feel comfortable just announcing such details to my adversaries. Having an exact version number leaks when, and how often you patch your production systems - even if the version is current. An adversary knowing the patch cycle, means that they know when you are the weakest.

The HTTP Host header probably most useful for the Netcraft Web Server Survey. But in terms of HTTP it shouldn't matter. That is why we have standards, so that clients and servers written by different vendors can work together.

rook
  • 47,004
  • 10
  • 94
  • 182
  • 2
    This was my thinking as well. – ZnArK Oct 26 '12 at 18:11
  • 6
    Insecure might be a bit much. Its a form of information disclosure, but that alone doesn't make it insecure because there is no definition of secure. – Steve Oct 26 '12 at 22:06
  • 2
    @SteveS information disclosure vulnerabilities are a low finding and are on nearly every penetration test report I write because it is default. This is also a CWE violation. – rook Oct 26 '12 at 22:46
  • stackexchange exposes it in the header – Ced Mar 23 '16 at 21:49
  • @Ced stack exchange has a lot of problems, did you load this page over HTTP? With a session? Hmm... – rook Mar 24 '16 at 01:48
  • Most of the things that you'd be worried about here - such as leaking how often you patch production systems - are easy to figure out anyway. If telling someone what version / server your software is using is causing any sort of security issue, you have bigger problems than this HTTP header. – monokrome May 16 '18 at 22:17
11

It's used for whatever you want to use it for. I've found it helpful in the past for reverse-engineering compliance issues; e.g. IIS breaks HTTP/1.1 (RFC 2616) in lots of ways, but most are to the benefit of the user in terms of performance and supported by most browsers. Actually most current browsers no longer comply with the rules in RFC 2616 (now 13 years old).

I've run into problems with bugs in HTTP server code and configuration in the past. Knowing what is running at the remote end is a great help to diagnosing and resolving these problems.

Yes, in Security 101 you're told that obscuring this kind of information improves security, IME the benefits are limited:

  • Script kiddies/automated attacks don't bother looking to see what software you are running - they just fire all their guns and hope for the best.

  • Anyone who is reasonably competent should be able to determine the server type (although I've not tried this with HTTP servers, a few years ago, I was conducting a survey of SMTP servers - with an average of 2.1 commands, I could find the type and take a good guess at the major version number of MTAs from 12 different vendors).

TRiG
  • 610
  • 5
  • 14
symcbean
  • 18,418
  • 40
  • 74
  • Great Answer, although, is there any benefit to exposing this information to the Internet? (public facing web applications) – ZnArK Oct 30 '12 at 06:28
  • 2
    The benefit is the debugging thing - I do a lot of development work on web services / automation - not every client is a browser with a user driving it. – symcbean Oct 30 '12 at 09:55
  • 1
    I could see a use for this in a development environment, but not on internet facing production systems. What benefit does it really provide to an organization to expose this information to the internet? – ZnArK Oct 31 '12 at 03:30
  • 1
    I think changing the server header to something generic adds a small amount of security at the cost of very little. Administrators and developers already know what software is running on a server, so disabling this information costs nearly nothing. Automated tools don't necessarily just fire and hope, it depends on the expense of the attack. If you want to maximize infection you choose targets wisely rather than spending time on ones that won't work. – Steve Sether Feb 11 '15 at 19:03
  • 1
    Even if the version is current, Knowing when, and how often you apply patches is valuable information. By observing when patches are applied, an attacker will know when your production systems are the weakest. – rook May 05 '17 at 18:44