A properly configured load balancer is going to drop this header if the client sends it, and then set it itself, with the request connection's ip being first, then the proxy ip being second. Every proxy after that should append its own ip to that header, then finally when the request reaches your app server, you should filter out your known proxy ips to be left hopefully with just the ip address of the connection the request was forwarded for, which was not set via any client header, and not able to be spoofed.

I'm sure plenty of lbs/reverse proxies and app servers don't set things, establish trust, or filter the header properly though, because, people, but it is easy to lock down.

Yeah we got dinged by our pentesters a few years ago because the LB didn't clear X-Forwarded-For headers. So you could just set some trusted IP into the X-Forwarded-For header and various ip whitelists went "Well, it came from there, so we gonna let it though".

Oops :)

It is one of these trust-based headers that need to be cleared at the edge of your network / trust zone.

I do not agree that the XFF header must be dropped and re-set. Doing so can in fact be harmful. There is a reason for preserving the chain of IPs, which is that it allows the app to use the rightmost-ish IP after skipping the known proxy IPs.

You do need to make sure only trusted parties get to add headers. Otherwise, you are letting the client freely define their own IP as seen by your server.

Dropping and re-setting the header at your trust boundary is just the simplest implementation of that. You could also count instances, or sign the header, but I don’t think there’s a standard for that, and it would mean quite some overhead.

I see it as a tradeoff. By dropping the header, one maintains trust, but one loses the ability to geolocate.

Instead of dropping, I maintain a list of trusted proxies, and I remove them from the list instead at the application level. The rightmost or final value is then the client.

> By dropping the header, one maintains trust, but one loses the ability to geolocate.

Not dropping. Dropping what the client sent, and recreating it yourself, with the client connection's ip address. The IP can still be geolocated, as much as an ip address can be...

AS numbers have a very rough mapping to a very wide spot on a map, but they are not at all guaranteed to be accurate or up to date, and applied more so back when we had plenty of ipv4 space left and enormous blocks were held by giant companies.

Nowadays, ipv4 address are much more fragmented, globally, and an ASN might own a ip block that says the ip is in Utah, but it has since been leased out to some VPS provider who attached it to a load balancer running in a datacenter in Germany.

There are better headers (or better yet a combination of headers) that can be used to get the user's location, and their locale (yes, where you live or connect from doesn't at all mean you speak the native language in that region).