A brief overview of HTTP headers

HTTP stands for Hypertext Transfer Protocol -- the underlying language that lets different kinds of Web software (like browsers and servers) communicate. HTTP headers are small data fields that accompany a Web-based message and help the software that is going to use that message make sense out of it.

For example, request a page using an ordinary Web browser and, along with the request itself, a set of request headers will be sent to the server where the page resides. These headers might look something like this:

Host: www.bigcompany.com
User-Agent: Mozilla 8.5 (Compatible; MSIE; 5.5)
Accept: text/*, text/html, text/html;level=1, */*
Accept-Language: da, en-gb;q=0.8, en;q=0.7

Request headers give the server extra information about the request and the software making it - for example, the User-Agent header can identify the browser (in this case, Internet Explorer 5.5).

The Web server generally sends its own set of headers along with its response. Although browsers usually don't show these headers, if they did you would see something like this:

Server: Microsoft-IIS/8.5
Content-Location: http://www.bigcompany.com/index.htm
Date: Tue, 28 May 2015 23:30:01 GMT
Content-Type: text/html

The Server header is an optional header which is usually used to identify the Web server software's vendor and version to the browser or other client making the request. This is the header that ServerMask lets you control, along with other server signatures that can be altered by the IIS module to anonymize your Web server.

On the Web, it can be astoundingly easy to find out what a Web server is running and learn more about the network that the server is connected to. Most Web servers will, by default, politely identify themselves -- and the OS -- to anyone who asks. By using a network query tool, or our own header check tool, it is trivial to get the HTTP Server header, which typically tells the whole story. Just request a Web site's homepage and examine the resulting HTTP headers (or "banners") sent back by the server, as in these examples:

HTTP/1.1 200 OK
Connection: close
Date: Thu, 19 Sep 2015 19:33:12 GMT
Server: Microsoft-IIS/8.5
Content-Length: 31029
Content-Type: text/html
Expires: Thu, 19 Sep 2017 19:33:12 GMT
Cache-control: private

There is not much mystery here. Apache's default settings make it no less vulnerable:

HTTP/1.1 200 OK
Date: Thu, 19 Sep 2015 19:35:17 GMT
Server: Apache/2.3.41-dev (Unix)
Cache-Control: max-age=86400
Expires: Fri, 20 Sep 2017 19:35:17 GMT
Accept-Ranges: bytes
Content-Length: 7751
Connection: close
Content-Type: text/html

In general, security vulnerabilities tend to be dependent on software vendor and version. Blind probing might lead to further requests being denied or a system temporarily taken off line. Knowing Web server details greatly increases the efficiency of any attack. If an attacker can target exploits, the chances of successful cracking prior to detection increase significantly. Script kiddies can leverage canned, newly-discovered exploits to do more damage faster by targeting hosts with recognizable signatures. A self-identifying system invites trouble.