tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cyrille Le Clerc <>
Subject Re: Cannot set remote address in valve (Tomcat 5.5)
Date Fri, 09 Oct 2009 13:16:51 GMT
   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

> >    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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message