DEV Community

facilishz
facilishz

Posted on

Tomcat RemoteIpValve needs a trusted proxy boundary

#securityengineering #cyber04tomcatremoteip

Tomcat RemoteIpValve needs a trusted proxy boundary

Applications often use the client address for rate limits, audit records, access rules, and session decisions. Behind a reverse proxy, the socket peer is the proxy rather than the user. Tomcat's RemoteIpValve can recover an apparent client address from a forwarded header, but that transformation is safe only when Tomcat knows which proxies are allowed to supply it.

The valve reads a header such as X-Forwarded-For, identifies internal or trusted proxies, and updates request IP and protocol information. Its configuration includes an internalProxies expression and related trusted-proxy settings. A broad expression can classify an address as trusted when it should not be. An unreviewed default can also be wrong after a network redesign.

What the valve changes

The review should start with the network path. Enumerate every proxy, load balancer, and ingress controller that can connect to Tomcat. Confirm that Tomcat's connector is not reachable from client networks. Then compare those source addresses and ranges with the valve expression. A private-range regex is not a trust policy if an unrelated service on the same private network can reach the connector.

Map proxy trust

Header handling is the next layer. A trustworthy proxy should overwrite or strip client-supplied forwarding headers before adding its own. If the edge passes X-Forwarded-For through unchanged, a client can add an address that Tomcat later treats as part of the chain. The valve's proxy processing reduces this risk only when the immediate peer is trusted and the chain is interpreted as designed. It cannot repair an edge that forwards arbitrary authority headers.

Validation tests

Useful tests include:

  • Send a forged forwarded header directly to the Tomcat port and confirm that it is rejected or ignored.
  • Send the same header through the approved proxy and confirm the expected result.
  • Repeat after adding a new proxy range or changing a load-balancer address.
  • Check application logs to verify that the recorded client address changes with the tested path.
  • Review rate-limit keys and allowlists that depend on request.remoteAddr.

Evidence and scheme trust

Audit events should retain both the apparent client address and the immediate peer when possible. If an incident review sees only the rewritten address, it may lose the ability to identify the proxy or detect a malformed chain. The proxy itself should log the original connection and the headers it generated.

A final review point is scheme and port trust. The same valve can influence protocol and host information used for redirects, cookie handling, and URL generation. A forwarded header that is acceptable for logging may be too powerful for building password-reset links or choosing a secure cookie flag. Separate those decisions in the application.

RemoteIpValve is a bridge between a proxy's view of the connection and Tomcat's request API. It should rest on a short, documented list of trusted peers and an edge policy that controls every relevant header. Treating all private addresses as trusted turns a useful adapter into an easy way to forge identity-adjacent request data.

References

Top comments (0)