Hello!

On Wed, Jan 13, 2021 at 11:39:13PM +0900, nanaya wrote:

> On Wed, Jan 13, 2021, at 22:53, Maxim Dounin wrote:
> > 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.
> >
>
> Unfortunately, at least in rails, it's actually dangerous passing the value as is:
>
> https://github.com/rails/rails/blob/3f4fde4d9f804140be8304b524792c052e3d1024/actionpack/lib/action_dispatch/middleware/remote_ip.rb#L21
>
> At least they have added a bunch of check to make it less
> dangerous even when using $proxy_add_x_forwarded_for
> (essentially works just like $remote_addr in default config).

This code seems to imply that the code is running behind a trusted
proxy, and both X-Forwarded-For and Client-IP headers are actually
updated by the proxy. And it uses a list of trusted proxies it is
going to trust to switch to a previous address, so I would say the
code is safe when used properly. And it's fine with
$proxy_add_x_forwarded_for, too.

Another question is how often it is used properly. Given it
requires update of two headers, at least one of them being very
rare, I would assume the answer is "almost never". But again, it
has nothing to do with $proxy_add_x_forwarded_for. Rather,
properly using "proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;"
will make attacks impossible.

> > 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.
> >
>
> Yeah, I'm not going to trust X-Forwarded-For sent by client.
> Maybe it's just me. $remote_addr to me is their geolocation.
> Anything more "sophisticated" just looked like a potential of
> failure.

Again: there is a difference between trusting X-Forwarded-For sent
by client and using it in the cases where trust isn't that
important. Certainly no one should blindly trust X-Forwarded-For.
But anyone can use it properly, and stripping it as you suggest is
just wrong in most cases.

> And I don't want to have to worry if my $random_app parses the
> X-Forwarded-For sanely. At most I'd just log it at the edge
> server.

That's your choice: instead of fixing vulnerabilities in the apps
you prefer to drop headers which might be used to exploit these
vulnerabilities, dropping also many legitimate uses of the headers.

> Look at this wonderful function by wordpress (thankfully they do
> aware it's "unsafe"):
>
> https://github.com/WordPress/WordPress/blob/c5d1214607be128c99dd27589a58cc5a1d20d522/wp-admin/includes/class-wp-community-events.php#L262

That's exactly what I'm talking about: as long as you don't need
trusted address, X-Forwarded-For can be used to extract some
valuable information.

Further, note that even with X-Forwarded-For set to $remote_addr,
client still can provide arbitrary address to the code via the
Client-IP header. So, if the code in question is somehow used to
extract an addresses where trusted address is actually needed,
your using $remote_addr instead of $proxy_add_x_forwarded_for
won't save you from being vulnerable.

> Semi unrelated but I can't find this list of IPs used by Opera
> Mini proxies. Do you know where I can find it?

A good list of trusted proxies is maintained by Wikimedia, see
here:

https://meta.wikimedia.org/wiki/XFF_project#Trusted_XFF_list

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx