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
