Akka-http: X-Real-IP should probably be preferred over X-Forwarded-For in _extraClientIP directive?

[timorantalaiho]

Hello,

I was happy to find a utility to find out the real client IP address in akka-http. However, it seems to prefer the first in list of X-Forwarded-For instead of X-Real-IP.

It seems that even though the leftmost value of X-Forwarded-For is generally the original client IP address, this is not universally so, and there exist modules for at least Apache and Nginx web servers to provide the correct resolution of the client IP address and setting it as the X-Real-IP value.

So maybe X-Real-IP should be prioritised over the first address of X-Forwarded-For?
There could also be a log message (at least on INFO level) if the X-Forwarded-For contained multiple addresses without the presence of X-Real-IP, preferable including the value of X-Forwarded-For.

[raboof]

I'm not so sure.

Usually the reason for using extractClientIP is for some kind of 'security' feature, where you know there are some proxies that you control in front of your application.

When using X-Forwarded-For, routers can append to the list of addresses, making the first value the 'original' IP. Of course, an attacker could add his own X-Forwarded-For of X-Real-IP header. It is up to you to configure your proxies to avoid passing along X-Forwarded-For or X-Real-IP headers from untrusted sources.

I don't see a clear reason to prioritize X-Real-IP over X-Forwarded-For. X-Forwarded-For could be a little more reliable when you have multiple proxies in your infrastructure, though you will indeed still be responsible to configure those proxies not to forward data from untrusted sources.

Moreover, we can't really reverse the behavior of extractClientIP at this point: that would mean users that have set up their proxies to publish the correct X-Forwarded-For could be compromised by attackers adding an X-Real-IP header.

Does that make sense? We should add this kind of information to the documentation btw.

[timorantalaiho]

Thanks, maintaining backwards compatibility is a very good point. I guess that our setup of determining the real client IP address by filtering out the trusted proxies from X-Forwarded-For (with ngx_http_realip_module of nginx) _and_ storing the real customer IP to X-Real-IP is coincidental in the end. We just have to refrain from using extractClientIP and read and log the relevant headers by ourselves.