Posted on October 18, 2021

Why It’s Important to Remove Header Details in Web Server Responses

Before a web page renders in a user’s browser, a request is made to the application host server. The server receives the request, processes it, and then sends a response to the browser. In an attack scenario, cyber-criminals use simple server request and response pairs to determine the architecture and infrastructure of the application. This can be used to launch targeted attacks on your application should you run outdated unpatched software.

Understanding Server Requests

When you type a URL into your web browser, it creates a request and sends it to the web server. There are two types of requests: GET and POST. A GET request is a simple “please send me the information based on the URL given.” In a POST request, data is submitted to the server for processing. POST requests are normally used in web forms and other input sent to the server. Attackers use both request types to discover vulnerabilities on the server, but a basic GET request is only required to view infrastructure information about the application and server software.

The following snippet is an example server request sent from your browser:

 

GET / HTTP/1.1

Host: yoursite.com

Accept-Language: en-US

 

The above request is a simple request using GET targeting the root of the site yoursite.com. You can identify that the root (home page) of the web application is requested because only the slash (“/”) character is included in the first line where GET is specified. The “HTTP/1.1” section tells the server that this is an HTTP request using version 1.1. If a specific directory or application file is requested, it’s included in the GET request. The “Accept-Language” header provides the language understood by the user. The user’s language is configured in the browser installation and passed in your web requests.

The following request is another example:

 

GET /mypage.htm HTTP/1.1

User-Agent: Mozilla/5.0 (compatible; MSIE5.01; Windows NT)

Host: yoursite.com

Accept-Language: en-US

Accept-Encoding: gzip, deflate

Connection: Keep-Alive

 

In the above request, the GET request asks for a specific file named mypage.htm from the yoursite.com website. In this request, the “User-Agent” header is included. This header identifies the browser used by the user requesting content.

POST requests look somewhat differently, because these requests are used to send information to the server either from a form or possibly an uploaded file. The following snippet is an example of a POST request:

 

POST /sendmessage HTTP/1.1

User-Agent: Mozilla/5.0 (compatible; MSIE5.01; Windows NT)

Host: yoursite.com

Content-Type: application/x-www-form-urlencoded

Content-Length: length

Accept-Language: en-US

Accept-Encoding: gzip, deflate

Connection: Keep-Alive

userid=myuser&message=hello

 

In the above the POST request sends the “userid” and “message” values to the application’s “/sendmessage” processing page. Attackers will send data to the web server to identify exploitable vulnerabilities, but a POST request is not necessary when researching servers to map out application architecture.

 

Understanding Server Response Headers

After the server receives a request, it processes it and sends a response back to the web browser. Server responses contain several more header values than a request. The following is an example of a server response:

 

200 OK

Access-Control-Allow-Origin: *

Connection: Keep-Alive

Content-Encoding: gzip

Content-Type: text/html; charset=utf-8

Date: Mon, 11-Jan-2021 16:06:00 GMT

Keep-Alive: timeout=5, max=997

Last-Modified: Mon, 21 Dec 2020 02:36:04 GMT

Server: Apache/2.4.9 (Unix)

Set-Cookie: userid=3454332; expires=Mon, 11-Jan-2021 16:06:00 GMT; Max-Age=31449600; Path=/; secure

Transfer-Encoding: chunked

Vary: Cookie, Accept-Encoding

X-Cache-Info: not cacheable; meta data too large

 

The important components in the server response for an attacker performing reconnaissance on your application are the first line (200 OK in this example) and the Server header value. A web application server could return several other header values, even custom ones created by server administrators and application developers.

The “200 OK” response means the request was processed successfully. An attacker may send various spoofed headers to the web server to identify if any vulnerabilities exists based on header information. For instance, the attacker might manipulate cookie values sent to the server to identify vulnerabilities or send malformed form input to identify if the server responds with an error. If an error occurs, the “200 OK” response would indicate an error such as a “500 general error.”

The other interesting component in the response is the Server header. The example response Server header value tells an attacker that the server runs Apache on a Unix operating system, most likely one of the Linux distributions. This information gives an attacker enough information to customize attacks on the server. If the server runs Windows, the headers will look like the following:

 

200 OK

Access-Control-Allow-Origin: *

Connection: Keep-Alive

Content-Encoding: gzip

Content-Type: text/html; charset=utf-8

Date: Mon, 11-Jan-2021 16:06:00 GMT

Keep-Alive: timeout=5, max=997

Last-Modified: Mon, 21 Dec 2020 02:36:04 GMT

Server: Microsoft-IIS/8.0

Set-Cookie: userid=3454332; expires=Mon, 11-Jan-2021 16:06:00 GMT; Max-Age=31449600; Path=/; secure

Transfer-Encoding: chunked

Vary: Cookie, Accept-Encoding

X-Cache-Info: not cacheable; meta data too large

 

Notice in the above example that the Server header returns Microsoft IIS, which is a Windows hosting service. In this scenario, the attacker might assume the application could be running .NET. In some cases, the server returns the application .NET framework information.

 

Server Headers and Targeted Attacks

It might seem harmless for anyone to know server operating system and framework information, but it’s useful information for targeted attacks. For instance, suppose Microsoft discloses a critical vulnerability affecting their Windows operating system. Attackers use disclosed vulnerabilities to craft attacks against servers where administrators have not patched its software. If the response headers define the software running on the server, an attacker knows that the server is vulnerable to exploits.

The severity of this risk can be seen in the Equifax attack, where millions of consumer records were disclosed to an attacker. Equifax administrators failed to patch critical web hosting software running on a publicly available server. Attackers were able to identify the outdated software and exploit the server. The result was one of the biggest data breaches to date.

 

Protecting Your Web Application from Targeted Server Attacks

To protect your server from targeted attacks, administrators should configure the web application server to leave the Server header value empty. Any web hosting software will allow this configuration including Apache, nginx, and Microsoft IIS. You can check out the hosting software documentation to find out how the header value can be removed.

With the Server header value removed, you make it one step harder for attackers to find vulnerabilities on your web application. It doesn’t fully protect your server from exploits, but it forces attackers to blindly script attacks rather than having the advantage of targeted attacks using known vulnerabilities and outdated unpatched software.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

Trusted by Clients Across All Industries

Don’t take our word for it - let our happy clients do the talking. See More

Full Host did an amazing job of migrating my site seamlessly onto their server. My only regret was not switching my site over to them sooner. Now it is performing great, images are uploading way faster than ever before.

" Vancouver Sofa and Patio - Jerry Schmidt

Two thumbs up for Fullhost! Agents reply to me fairly quickly or at least let me know they received the ticket and are looking into it. Kudos to the support team as they have always given me exactly what I need without delays.

" Universal Staffing Inc. - Anthony Calvano

FullHost is an absolute pleasure to work with, and their customer service is exceptional. Whenever I have questions or need adjustments, they are there to help, quickly, efficiently, with answers and insights.

" Mooseworld Inc. Norine Leibel

With coast to coast coverage,
We help you serve the world.

Whether your audience is located in Europe, Asia, Africa, or Australia, provide them with lightening speed!

FullHost's data centers are located in Toronto and Vancouver to ensure worldwide quality and speed.

Get in Touch
We Trust Only The Best Tech to Support You

FullHost operates with the most innovative technology to bring you unparalleled levels of hosting services.