Re: I-D draft-petersson-forwarded-for-00.txt

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