Wednesday, July 17, 2013

Internal IP Address Disclosure over HTTP Protocol Channel : Information Revealing Headers !

The disclosure of internal IP addresses to remote users reveals a substantial layout of the organizational network. It is highly advised that the web servers should not disclose internal IP addresses in the HTTP response headers. In a real time scenarios, this is not the case. The majority of web servers, load balancing devices and web applications disclose this information. This post simply discusses the different ways through which internal IP addresses are revealed over HTTP protocol.

You can read more about HTTP 1.1 specifications and working here:

1. Location Response-Header Field:  This response header is basically used for redirecting the HTTP request to a new location. It results in 201 response code when resource is dynamically created during the request. The 3xx (redirection 301, 302, 303, 304, 305, 306, 307) response value shows that location is predetermined by the web server and is the preferred one.

2. Content-Location: Similarly, Content-Location response header also discloses the internal IP address. This header presents a location of the resource when it is accessible on a separate URI in addition to the HTTP request. There is a potential issue in IIS web servers which reveal internal IP address in Content-Location header while redirecting the browser. More details can be read here:

There is a difference between in the usage of Location and Content-Location HTTP response headers. For reference, you can read this blog entry:

3. Via Header Field: This HTTP response is header is distributed by gateways and proxies present between the client (user agents - browsers) and the web server. The basic functionality of Via header field is to track message forwarding, avoid loops during processing and identifying protocol capabilities. Generally, this header reveals the internal IP address of the configured gateway or proxy as shown below:

 4. X-Cache Header: This response header is thrown by transparent proxies deployed as an intermediate agent between the client and server. The idea is to simply reduce the direct load on the website by placing a copy in the cache and responding with the same when HTTP request is initiated by the client. There are other functionalities associated with transparent proxies also. The internal IP address can be revealed in two scenarios as discussed below:

4.1 X-Cache Miss: When the transparent proxy does not have a local copy of the website or web pages requested by the client.

4.2 X- Cache Hit:  When the transparent proxy has a local copy of the website or requested web pages.

You can read more about the X-Cache headers here:

5. Set-Cookie Header:  A number of load balancing devices use Set-Cookie for setting custom content as a part of communication channel to activate the session with the backend web server. The internal IP address can also be disclosed as a part of Set-Cookie parameter. A simple example is the BIG IP devices which basically reveal the internal IP address in binary encoded form.  Be default, it is the functionality of BIG IP devices to handle HTTP connection pooling based on IP addresses. In the screenshot shown below, the pool parameter holds the value of internal IP address

In my earlier presentations (couple of years ago), I talked about extracting the IP address from the BIG IP http_pool Set-Cookie parameter. The concept is shown below.

These are the some of the HTTP headers over which internal IP is exposed. While deployment, one should verify and validate that these headers should not expose unnecessary information.

Note: If anyone has additional information regarding Internal IP address disclosure over HTTP channel, let me know and I will update this entry. The idea is to collect all the metrics.



Hildegarde said...

This is great!

Aditya K Sood said...

Glad the information is useful.

Mohammad Hesabi said...

so how can I avoid this happening on IIS 7.5?

Mohammad Hesabi said...

can you please explain how to avoid this?

Anonymous said...