adryd
(adryd)
February 8, 2023, 1:51am
1
Not sure where or if this is appropriate to post, but I felt the need to notify people of this bug as it has security implications for those who use this plugin. The plugin has a fair amount of downloads on caddyserver.com
I’ve opened an issue Security: trust_header overwrites req.RemoteAddr globally · Issue #4 · shift72/caddy-geo-ip · GitHub , however I feel like users of the plugin are more likely to see it here.
when the trust_header directive is set in caddy-geo-ip, it overwrites req.RemoteAddr to the value of the header. This then gets passed down to other plugins and directives which share the same request.
example.com {
geo_ip {
db_path /var/lib/GeoIP/GeoLite2-City.mmdb
trust_header X-Forwarded-For
}
respond /test 200 {
body "Remote Address:{remote_host}"
}
}
With the above config curl https://example.com/test -H "X-Forwarded-For: 1.1.1.1"
would respond with Remote Address:1.1.1.1
showing that the value was changed outside of the geoip scope
This could allow people to bypass IP range restrictions and perhaps many other things I haven’t thought of.
1 Like
Thanks for bringing that up.
FYI, Caddy will soon have an official and secure way to determine the client IP:
caddyserver:master
← caddyserver:real-client-ip
opened 05:22AM - 01 Oct 22 UTC
Followup on #5103 and #5328.
This introduces first-class support for determin… ing the client IP, at the HTTP server level. Also adds a placeholder and writes it to the access logs.
I'm marking this as a draft for now, because this has a certain level of risk, and needs discussion. We need to be extra careful about the implementation.
I'm taking @adam-p's guidance on this from his excellent article https://adam-p.ca/blog/2022/03/x-forwarded-for/. There's a few different valid approaches to this. This implementation takes the left-most, first valid IP. I'm _not_ excluding private IPs, because actually it happens frequently that users want their LAN IP to be used as the real client IP, in home networking contexts.
~~Currently, the header used is not configurable, I have it just set to `X-Forwarded-For` which is typically good enough, but I think to be robust we'll need to make that configurable. Do we only allow a single header field, or do we allow a fallback list?~~ I implemented this as a fallback list of headers. This is configured on the server itself, alongside the `trusted_proxies`.
~~Another open question (also applicable to #5103, maybe we should figure this out before merging that), should we make trusted IP sources pluggable?~~ We did make it pluggable in #5328. We provide a "static" module by default. The argument for that is that proxies like Cloudflare have a ton of IP ranges, and users managing that in their config is annoying. So a plugin module would be able to periodically fetch and cache their IP list.
I decided that the `client_ip` should always be set (as long as the `RemoteAddr` is a valid IP address). So in the logs, it will be identical to the `remote_ip` unless trusted proxies is configured and the proxy passed the client IP in a trusted header.
system
(system)
Closed
March 10, 2023, 1:52am
3
This topic was automatically closed after 30 days. New replies are no longer allowed.