Reproduce incorrect IP address with multiple reverse proxies #2357
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a reproduction of #2351, where the incorrect visitor IP address is resolved when Shlink is served behind a chain of two or more reverse proxies.
In here, three reverse proxies are configured in front of Shlink, with the next IP addresses:
I tried to visit every proxy, and see what IP addresses were resolved and set in every relevant header, and these are the results:
akrabat/ip-address-middleware ^2.5
shlink (trusted_proxies: [])
shlink_proxy_one (trusted_proxies: [])
shlink_proxy_two (trusted_proxies: [])
shlink_proxy_three (trusted_proxies: [])
shlink_proxy_one (trusted_proxies: ['172.20.16.15'])
shlink_proxy_two (trusted_proxies: ['172.20.16.15', '172.20.16.17'])
shlink_proxy_three (trusted_proxies: ['172.20.16.15', '172.20.16.17', '172.20.16.18'])
akrabat/ip-address-middleware 2.4.0
shlink (trusted_proxies: [])
shlink_proxy_one (trusted_proxies: [])
shlink_proxy_two (trusted_proxies: [])
shlink_proxy_three (trusted_proxies: [])
Conclusion
akrabat/ip-address-middleware: ^2.5
introduced a regression in order to fix a potential security issue. This is unfortunate, but there was probably not backwards-compatible way to solve it.The result is that, while before, the first IP from the left was picked from
X-Forwarded-For
, now the first IP from the right which is not a trusted proxy is picked instead, so now it's required to set trusted proxies to retain the previous behavior.Also, changing the order in which headers are checked to inspect
X-Real-IP
first would not solve the problem, as every proxy sets the IP of the previous one there, so we would still not resolve the visitor IP address when there's two or more proxies.