Usage of $proxy_add_x_forwarded_for on edge proxies

[Maxim Dounin]

Hello!

On Wed, Jan 13, 2021 at 06:50:47AM +0900, nanaya wrote:

> On Wed, Jan 13, 2021, at 02:46, Maxim Dounin wrote:
> > The X-Forwarded-For is expected to contain multiple addresses, with 
> > the last one being from the last proxy.  It is up to the reader of 
> > the header to trust or not particular values from the header.
> > 
> > For example, in the realip module nginx provides set_real_ip_from 
> > and real_ip_recursive directives to configure which addresses to 
> > trust (see http://nginx.org/r/set_real_ip_from and 
> > http://nginx.org/r/real_ip_recursive).  Similarly, in the geo 
> > module there are "proxy" and "proxy_recursive" parameters, and in 
> > the geoip module there are "geoip_proxy" and 
> > "geoip_proxy_recursive" directives.
> > 
> > In some cases it might be a good idea to trust X-Forwarded-For 
> > values provided by clients: for example, the are some well-known 
> > public proxies, such as Opera Mini proxies.  And it might be a 
> > good idea to trust almost everything if you are trying to extract 
> > some non-essential details, such as best-guess geoinformation.
> > 
> > And it is always a good idea to preserve X-Forwarded-For provided 
> > by client, if any.  In particular, it can be used in abuse reports 
> > and various investigations.
> > 
> > If you want to use something without extra complexity, consider 
> > using X-Real-IP header instead, which is expected to contain only 
> > one client address as set by your edge/frontend servers.
> > 
> 
> Is it not better to just handle all of those at the outermost 
> proxy (with set_real_ip_from etc) and only pass the "sanitized" 
> $remote_addr value to the upstream? At least for simple config, 
> similar to the default REMOTE_ADDR in fastcgi_params etc.

Consider an application which needs both trusted address and a 
best-case geoinformation, as well as some data for abuse reports.  
The only option is to preserve X-Forwarded-For got from the 
client.

> It seems like a lot of potential point of failures trying to 
> pass the value around. And people sharing this possibly 
> dangerous config around without warning of its implication isn't 
> helping, I think.

It's not "dangerous config", it's incorrect usage of 
X-Forwarded-For which might be dengerous.  In the most simply 
configuration with a single server the X-Forwarded-For header 
comes directly from the client, without anything added by nginx - 
and this has exactly the same implications.

> I guess X-Real-IP could work although I don't remember seeing it 
> used by anything but nginx. And then I think there have been a 
> bunch of problems caused by applications blindly trusting 
> X-Forwarded-For which usually ends up with stripping everything 
> but the last non-private ip by default - essentially a more 
> complex version of outermost proxy passing $remote_addr for that 
> header.

While X-Forwarded-For is often misused by applications and 
incorrect configurations by blindly trusting addresses in it, 
removing the header is going to make destroy the information 
available for well-written applications.  While you it might be a 
good idea to remove the header in your particular use case - if 
you are sure enough your applications doesn't use it - this is 
certainly not how things should be configured by default.

-- 
Maxim Dounin
http://mdounin.ru/