Hello Christopher, > > I am afraid there may be a flaw in the algorythm looking for the > > first IP of the coma delimited x-forwarded-for header without > > ensuring that this first IP has been set by a trusted proxy and not by > > the requester ( getFirstIP(xforwardedForHeaderValue) ). Such spoofing > > can easily be achieved with tools like Firefox add-ons Modify Headers > > (1) and X-Forwarded-For Spoofer (2) . > > This is a good point that you've raised, here: it's a lot easier to > spoof an HTTP header than it is to spoof a source IP address in an IP > packet.
An idea to mitigate this risk is to ask the network team to remove some http headers at the entry of the platform (x-forwarded-for, x-forwarded-proto, x-forwarded-... ) but the coordination between application and network teams this requires can be difficult to achieve. > > The forthcoming version of Apache Httpd will offer a secure > > mechanism to handle X-Forwarded-For with a module called mod_remoteip > > (3). It relies on the concept of trusted proxies which IP address can > > be 'swallowed'. The first IP of the list that is not a trusted proxy > > is seen as the real remote ip. mod_remoteip would not have been > > tricked by such x-forwarded-for header spoofing. > > Uh.... huh? That seems counter-intuitive to trust the first untrusted IP > address you find. I'll read about mod_remoteip and see what it's all about. My mistake, I forgot to mention that it was evaluating from the right to the left. Let's imagine my http request goes through : client -> hardware-load-balancer -> apache + mod_proxy_http -> tomcat With load-balancer configured to overwrite x-forwarded-for and apache mod_proxy_http appending the incoming ip to x-forwarded-for header (out-of-the-box configuration). In tomcat, i will have : * request.remoteAddr = @apache * http header x-forwarded-for: "@client, @hardware-load-balancer" the RemoteIpValve (or XForwardedFilter) wil process : * evaluate x-forwarded-for values from right to left : 1. @hardware-load-balancer is swallowed as a trusted proxy 2. @client is the first un trusted ip address, trust it (because the hardware-loadbalancer handling of x-forwarded-for header can be trusted ) * overwrite request.remoteAddr and request.remoteHost with value @client In a scenario of x-forwarded-for header spoofing coming with value "@fake", either : scenario a) The hardware-load-balancer would have overwrittent the header x-forwarded-for scenario b) The RemoteIpValve (or XForwardedFilter) would have received x-forwarded-for: "@fake, @client, @hardware-load-balancer" and still elect @client as the remoteAddr because it is the first "not trusted ip". Hope this clarifies the behavior of the anti spoofing algorithm of mod_remoteip. Cyrille --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
