Validate X-FORWARDED-FOR contains what we expect in ip endpoint
ameihm0912 opened this issue · comments
In getIP() in the API, we look for an IP address in X-FORWARDED-FOR and return it if found. No validation occurs to confirm it is a valid IP, we could add a check here since the intent is for it to be used in the agent environment, and only return it if it's what we'd expect to be there.
Maybe also consider whether certain IPs in X-FORWARDED-FOR are acceptable too. For instance, if someone provided X-Forwarded-For: 127.0.0.1.
Note this can actually result in a bug, but it's under a rare circumstance.
If agents are configured to connect via proxies, and the API is being offered without TLS (just HTTP), the append behavior for X-Forwarded-For will result in the comma delimited list of IPs being returned from the proxy path (if more than one are involved), which will panic the agent if it requests it's public IP.
Any API actually deployed should have TLS in front of it, in which case only a single X-Forwarded-For value should be present (added by the TLS termination) for a valid request.
@jvehent do you have any thoughts on if we should maintain support for running the API without TLS? If so, we would need some extra logic around how to handle the X-Forwarded-For header. It seems like a good idea given the standalone installer deploys it like this.
As an example, maybe an API configuration option that says when it should be preferred over the sockets peer address. For example when an agent is connecting through a proxy to a non-TLS API directly, we will not want to use X-Forwarded-For as the public address.