{{ message }}
Repository navigation
Incorrect X-Forwarded-For header parsing #423
Description
The X-Forwarded-For header is parsed incorectly in THttpRequest::originatingClientAddress() function:
- There may be multiple X-Forwarded-For headers in request.
- The originatingClientAddress() does not check whether clientAddress() is trusted proxy - the clientAddress() is not included in X-Forwarded-For.
- When splitting X-Forwarded-For don't use Tf::SkipEmptyParts.
See article:
https://httptoolkit.com/blog/what-is-x-forwarded-for/
Also there is no possibility to define proxy IP ranges.
Such a feature would be useful for TreeFrog to be able to work with Claudflare proxy servers:
https://www.cloudflare.com/ips/
Some time ago I made a pull request #296 that helps solving these problems (except bug 1), but was not merged.
Activity
treefrogframework commentedon Oct 23, 2025
Thanks.
The pull request #296 rejected because UNIX domain communications were given special treatment.
In modern proxy/cloud services, the behavior of “merging into a single header” is recognized as being relatively standardized.
Please tell me under what circumstances multiple X-Forwarded-For headers occur. HTTPS?
amiart commentedon Oct 23, 2025
Thank you for reply.
When I wrote #296, I based it on the ngx_http_realip_module:
https://nginx.org/en/docs/http/ngx_http_realip_module.html
It has a
set_real_ip_fromparameter, which could be set tounix:to specify that the server should trust the proxy communicating via a Unix domain socket.I realize that most proxy servers join X-Forwarder-For headers into one. However, for security reasons, it is recommended not to rely on this:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-For#parsing