Proudly Hosting over 100,000 Fast Websites since 2010

How to Fix: Web Server HTTP Header Internal IP Disclosure

How to Fix Web Server HTTP Header Internal IP Disclosure

Have you ever checked your web server access logs and noticed internal IP addresses, server identifiers, or other potentially sensitive network details? This likely means that HTTP request headers like X-Forwarded-For or X-Real-IP are getting logged and exposing your private infrastructure topology.

While proxies and load balancers add these headers for good reason, inadvertent logging of header values in web apps is an extremely common misconfiguration. The good news is that preventing internal IP disclosure is quite easy once you know how these headers work and where they can leak from.

In this comprehensive guide, we’ll cover everything you need to know to identify and fix HTTP header-related IP leaks including modifying proxy configurations, sanitizing values, securing logs, and adding protections with a web application firewall. Follow these best practices and you can drastically reduce the risk of your web apps unintentionally revealing internal network IPs or architecture.

What Causes Internal IP Exposure?

First, let’s look at the two HTTP request headers that typically result in internal IP leaks:

X-Forwarded-For

This header is added by proxy servers and reverse proxies to track the original client IP address through multiple layers of proxies. Here is what an example value might look like:

X-Forwarded-For: 198.51.100.2, 203.0.113.76, 203.0.113.10

This contains the originating client IP (198.51.100.2) and the proxies it passed through to reach the web server.

X-Real-IP

Some load balancers and reverse proxies add this header containing the true client IP, since they mask the source IP when forwarding requests.

X-Real-IP: 198.51.100.2

Now, if the web server inserts these headers directly into logs or returns them to clients, internal IP addresses will get exposed.

Preventing IP Leaks

Here are the key steps you need to take:

1. Strip Unnecessary Headers

See if you actually need these headers first. For example, Nginx as a simple reverse proxy/load balancer in front of a Node app server doesn’t require them.

Consider stripping out the headers entirely to avoid blindly passing them along.

2. Sanitize Header Values

If the headers are required by the backend application, sanitize the values first:

X-Forwarded-For: PRIVATE 

X-Real-IP: PRIVATE

This ensures no internal server IPs or network details leak through.

3. Disable Logging

Explicitly configure your web server to avoid logging these headers.

For Nginx, use the $http_x_forwarded_for variable to disable access logs:

access_log /var/log/nginx/access.log main if=$http_x_forwarded_for = “”;

Apache can be configured similarly to skip certain request headers in logs.

4. Restrict External Access

Block external access to internal address exposing logs with firewall rules and authentication.

Disable exposing connection or request handler metadata which might reveal network information.

For Nginx, disable the server tokens module to hide version details.

5. Add a Web Application Firewall

A WAF provides threat protection and can sanitize suspicious HTTP headers. Open source options like ModSecurity can filter and validate headers.

Here’s a sample rule to scrub internal IPs:

SecRule REQUEST_HEADERS:X-Forwarded-For “@ipMatch 127\.0\.0\.1” “setvar:’tx.real_ip’=127.0.0.1”

Testing for IP Exposure

Use online services to check if your headers expose internal IPs after reconfiguring your stack. Sites like IPLeaked.com simulate requests via proxies to test for leaks.

You can also use curl locally:

$ curl -H “X-Forwarded-For:192.168.0.5” www.myserver.com

Or check your application access logs for headers exposing IP addresses.

Final Thoughts

HTTP headers leaking IP addresses may seem like a minor issue initially. But apart from exposing your internal network, it also highlights that your configurations need improvement to prevent subtle data leaks.

Preemptively harden your web apps, implement protections like WAFs, and continuously test headers and logs. This best practice approach helps make sure that your web-facing assets don’t reveal more than intended.

And as you add new proxies, CDNs, middleware, and apps, be mindful of how HTTP headers propagate through them. Evaluate if values need to be passed along at all or require sanitization.

Proactively eliminating unintended data exposure will drastically improve your security posture in depth. So take the time to fix HTTP header leaks correctly – your infrastructure will be much safer for it.

Facebook
Twitter
LinkedIn
Reddit

Leave a Reply

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