- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 28 Apr 2011 20:19:56 +0200
- To: Andreas Petersson <andreas@sbin.se>
- Cc: Mark Nottingham <mnot@mnot.net>, "Thomson, Martin" <Martin.Thomson@commscope.com>, Karl Dubost <karld@opera.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Thu, Apr 28, 2011 at 05:04:03PM +0200, Andreas Petersson wrote: > > > src/from and dst/to should be unique within one proxy step. > > > > I'm not sure what you mean here. > > There should not be both src6 and src4 present. Inside a single step, I agree, but I did not propose to post the info twice, only once per step. Ah I think I understand. You mean that instead of having "src4" or "src6" we could simply have "src". Yes of course. I'd even say that either we have "family= ; src=;" or we have "src6=" and can get rid of the family. (...) > > which results in : > > Forwarded: from=[2001::1:2:3, from=[2002::5:6:7]:12345; to=[2002::8:9:A]:80 > > > > It's expected that many server-side parser will parse it that way : > > from=[2001::1:2:3, from=[2002::5:6:7]:12345 > > to=[2002::8:9:A]:80 > > > > Then they'd strip the address around the first opening bracket and the > > last closing one (strchr/strrchr), and pass their own inet_pton() over > > the result : > > my_inet_pton("2001::1:2:3, from=[2002::5:6:7") > > > > They's get 2001::1:2:3, happily ignore the error pointing to the comma > > and result in using the attacker-fed address as the source, with the > > proxy-fed port as the port. > > Is this a problem in all other places where you have brackets? I don't precisely know, I'm sure people are more careful when it comes to something that is planned at the beginning of their work. The use of the proxied IP address generally comes after deployment and is done as a quick and dirty hack. What I experience a lot is the following scenario : - a guy contacts me and tells me "hey, I have installed your haproxy and now my server only sees its IP address instead of my client's, how do I have to configure it ?" - I explain that he has to enable logging of the "X-Forwarded-For" header in his application or on his server (depending on his needs) ; - then the same guy comes the next day later saying "your haproxy has another bug, it randomly sends me corrupted headers which look like this : X-Forwarded-For: 192.168.1.2, 10.0.0.1 and this makes my server do [insert your favorite horror story here]" - then I point to the spec and explain how he must parse it, and insist that his server should never have performed the horror described above. - only after that I get "OK it works thanks". So basically, this is the type of thing that is often developped in a hurry because they discover they need it when it's already too late. Given the horrors I've read (application crash, session loss, ...) and the references they're systematically pointing as "the spec" without knowledge of header folding (http://en.wikipedia.org/wiki/X-Forwarded-For), I'm sure quite certain there is no reason for the situation to change whatever we describe. > I have hard to believe we can specify the standard in a way that > totally eliminates the need for input sanitation. I perfectly agree. However, some error patterns are more common than other ones, and when we know that some practices tend to trigger them quite often while other practices don't, I tend to stay on the side of not triggering them. > > Last point is that right now apps don't care about the port as it's the > > proxy's role to log it. Apps want the IP address for statistics, tracking, > > gelocation, etc... I predict that if we make it optional, almost nobody > > will enable it because they don't care a dime. Thus, let's not force > > everyone to complexify their parsers because we added information they're > > not interested in. > > I can agree to some extent, I see your point. Do others have an opinion > here? > > > /Andreas Petersson Regards, Willy
Received on Thursday, 28 April 2011 18:21:03 UTC