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/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx