Hi Matthieu,
On Thu, Sep 15, 2011 at 01:55:22PM +0200,
matthieu.lochegn...@altissemiconductor.com wrote:
> Hi,
>
> I'm facing a problem with the 'X-Forwarded-For' header.
> Although the HTTP RFC (2616) allows multiple occurences of the same header
> field, and describes how the values must be merged together, this is not
> correctly implemented by some servers.
> Especially JBoss or gSOAP only give one of the occurences to the target
> service, which cannot get nor build the whole 'X-Forwarded-For' comma
> separated list.
Then why not raise bug reports to those products ? In some circumstances,
it can even cause important security issues. Try to send them a POST
with two content-length headers, one large then one small. If it is
accepted it's possible that you can perform HTTP smugling attacks on
them.
> So I have added a 'concat' keyword to the 'forwardfor' option, to have
> HAProxy append the client's IP address to the existing 'X-Forwarded-For'
> header, like traditional Squid proxies do.
> I am not sure of the correct behaviour this keyword should have together
> with the 'header' keyword.
> With the patches below, the 'X-Forwarded-For' header values are moved to
> the specified header, and the client's IP address is appended to the
> list.The old header is removed, the new one is added at the end of the
> header list.
I strongly disagree about such a change for two reasons :
- first, we can't have options to workaround all known products bugs,
or configs will become quite awful and unmtainainable.
- second, the way it is done makes the issue even worse as it now
allows a client to hide its address : just send two xff headers,
the first one will be modified by haproxy and the last one will
remain. A sane product will consult the last one and see the
address forged by the client.
Oh and you can't simply change the logics to adjust the last header instead
as it will not work with your buggy servers : haproxy would then change the
last occurrence which will be ignored by the buggy servers, so they will
still use only the client's information.
So this is the wrong way of working around a dangerous server bug in my
opinion and I really refuse to introduce nasty security issues that are
hard to debug just because some products don't minimally follow protocols.
The solution to your issues with those products is to remove the XFF
header and let haproxy put its own version. As long as you let your
clients send more than one header with those servers, you're screwed
anyway. So basically you'd have this :
reqidel ^x-forwarded-for
option forwardfor
Note: there are people who prefer to rename the old header instead of
removing it. It's just a matter of taste.
Regards,
Willy
