`request.getRemoteAddr()` is not a propagator for untrusted data

[seqradev]

Summary

HttpServletRequest.getRemoteAddr() and related TCP-level accessor methods are currently treated as propagators of untrusted data because the taint analysis taints the entire HttpServletRequest object. Calling any method on a tainted request — including getRemoteAddr() — propagates taint to the return value. This is incorrect: these methods return network-stack information determined by the TCP connection, not by attacker-controlled HTTP content. The result is false positives when values from these methods flow into sinks.

Problem

The library source rules taints the HttpServletRequest parameter as a whole in servlet entry. The engine treats every get* method call on it as a taint propagator — including methods that return TCP-level metadata which is not part of the HTTP request body, headers, or query string.

request.getRemoteAddr() returns the IP address from the underlying TCP socket. This value is determined by the network stack, not by anything the HTTP client sends in the request. An attacker cannot set it to an arbitrary value through normal HTTP traffic. Treating it as untrusted leads the engine to flag code paths like logging the caller's IP, IP-based rate limiting, or audit trails — all of which are safe and expected uses.

The same applies to the following related methods that also return TCP connection metadata:

• getRemoteHost() — DNS reverse lookup of the remote address
• getRemotePort() — TCP source port
• getLocalAddr() — server-side local address
• getLocalPort() — server-side local port
• getLocalName() — server-side local hostname

These methods should not propagate taint from the request object to their return values.

Notes

We can define the TCP-level methods as sanitizers — so that calling them on a tainted request object does not propagate taint to the return value.