Hi, I've realized of a small vulnerability in Pound:

I've made a spoofed HTTP request adding a "X-Forwarded-For: 1.2.3.4" header 
and sent it to Paund. When Pound receives it, it adds a new "X-Forwarded-For: 
SOURCE_IP" but the added header is at the bottom of the request:


The request arriving to Pound:

T 2009/09/12 21:49:44.271221 87.218.216.202:52448 -> 99.122.79.215:9080 [AP]
GET /xcap-root/pres-rules/users/ibc(at)qwe/presrules HTTP/1.1
Content-Length: 0
X-Forwarded-For: 1.2.3.4


The request forwarded by Pound to the web server:

T 2009/09/12 21:49:44.271452 127.0.0.1:36734 -> 127.0.0.1:80 [AP]
GET /xcap-root/pres-rules/users/ibc(at)qwe/presrules HTTP/1.1
Content-Length: 0
X-Forwarded-For: 1.2.3.4
X-Forwarded-For: 87.218.216.202


Most of the web servers I know just inspect the top-most header, so when 
inspecting "X-Forwarded-For" they would get "1.2.3.4" instead of "SOURCE_IP".

In my case I'm developing a XCAP server (RFC 4825) and my aim is using Pound 
in front of a cluster of web XCAP servers. A XCAP server must require Digest 
authentication depending on the URL but it doesn't ask for authentication if 
the request comes from a trusted IP. Being behind a http proxy the only way to 
know the source IP is by inspecting the "X-Forwarded-For" value. However, the 
client could spoof it as I describe above.

A workaround would be using "HeadRemove" but I think that Pound should do it 
by default (remove all the "X-Forwarded-For" headers present in the original 
request).

Regards.


-- 
Iñaki Baz Castillo <ibc(at)aliax.net>

> X-Forwarded-For: 1.2.3.4
> X-Forwarded-For: 87.218.216.202

I believe that's legal, and is equivalent to:

X-Forwarded-For: 1.2.3.4, 87.218.216.202

Possibly the IPs in my example are reversed - I'm not sure.  The point 
I'm making is that if you require only a single IP to be in your 
X-Forwarded-For header, you should use HeadRemove as you mentioned.

The multiple-IP version is legal / arguably desirable in the case of 
multiple intermediate proxies.  Think ISP-level web accelerator in front 
of an end-user.

Regards,
-- 
Dave Steinberg
http://www.geekisp.com/
http://www.steinbergcomputing.com/

El Sábado, 12 de Septiembre de 2009, Dave Steinberg escribió:
> > X-Forwarded-For: 1.2.3.4
> > X-Forwarded-For: 87.218.216.202
> 
> I believe that's legal, and is equivalent to:
> 
> X-Forwarded-For: 1.2.3.4, 87.218.216.202
> 
> Possibly the IPs in my example are reversed - I'm not sure.  The point
> I'm making is that if you require only a single IP to be in your
> X-Forwarded-For header, you should use HeadRemove as you mentioned.
> 
> The multiple-IP version is legal / arguably desirable in the case of
> multiple intermediate proxies.  Think ISP-level web accelerator in front
> of an end-user.

Yes, it makes sense but then each X-Forwarded-For header added by each proxy 
should be on top of others. In the example I wrote:

The request arriving to Pound:

T 2009/09/12 21:49:44.271221 87.218.216.202:52448 -> 99.122.79.215:9080 [AP]
GET /xcap-root/pres-rules/users/ibc(at)qwe/presrules HTTP/1.1
Content-Length: 0
X-Forwarded-For: 1.2.3.4


The request forwarded by Pound to the web server:

T 2009/09/12 21:49:44.271452 127.0.0.1:36734 -> 127.0.0.1:80 [AP]
GET /xcap-root/pres-rules/users/ibc(at)qwe/presrules HTTP/1.1
Content-Length: 0
X-Forwarded-For: 87.218.216.202  <--- ON TOP
X-Forwarded-For: 1.2.3.4


I'm used to SIP protocol in which there are scenarios with multiple proxies 
adding headers (as "Via" and "Record-Route" header). When a proxy adds a Via 
or Record-Route header it *must* write it on top of existing Via/Record-Route 
headers. I expect that in HTTP it should be the same as SIP is "based" on 
HTTP.

Regards.


-- 
Iñaki Baz Castillo <ibc(at)aliax.net>

Greetings,

The expected format for all XFF headers is that there's only ONE XFF header.
Every proxy server appends the client IP to the end of the XFF IP list.

e.g.

my IP: 10.0.0.1
proxy A: 202.41.76.251
Proxy B: 128.10.2.10 (let's say this is Pound)
webserver: 172.16.10.1

the webserver should receive an XFF header line as:

X-Forwarded-For: 10.0.0.1, 202.41.76.251

That's how all servers and log analyzers and plugins expect it.

Multiline XFFs aren't the norm, and shouldnt be encouraged

-- Saumil


--- On Sun, 9/13/09, Iñaki Baz Castillo <ibc(at)aliax.net> wrote:

> From: Iñaki Baz Castillo <ibc(at)aliax.net>
> Subject: Re: [Pound Mailing List] Pound: "X-Forwarded-For" should be deleted
if present in the request
> To: pound(at)apsis.ch
> Cc: "Dave Steinberg" <dave(at)redterror.net>
> Date: Sunday, September 13, 2009, 7:30 AM
> El Sábado, 12 de Septiembre de 2009,
> Dave Steinberg escribió:
> > > X-Forwarded-For: 1.2.3.4
> > > X-Forwarded-For: 87.218.216.202
> >
> > I believe that's legal, and is equivalent to:
> >
> > X-Forwarded-For: 1.2.3.4, 87.218.216.202
> >
> > Possibly the IPs in my example are reversed - I'm not
> sure.  The point
> > I'm making is that if you require only a single IP to
> be in your
> > X-Forwarded-For header, you should use HeadRemove as
> you mentioned.
> >
> > The multiple-IP version is legal / arguably desirable
> in the case of
> > multiple intermediate proxies.  Think ISP-level
> web accelerator in front
> > of an end-user.
> 
> Yes, it makes sense but then each X-Forwarded-For header
> added by each proxy
> should be on top of others. In the example I wrote:
> 
> The request arriving to Pound:
> 
> T 2009/09/12 21:49:44.271221 87.218.216.202:52448 ->
> 99.122.79.215:9080 [AP]
> GET /xcap-root/pres-rules/users/ibc(at)qwe/presrules HTTP/1.1
> Content-Length: 0
> X-Forwarded-For: 1.2.3.4
> 
> 
> The request forwarded by Pound to the web server:
> 
> T 2009/09/12 21:49:44.271452 127.0.0.1:36734 ->
> 127.0.0.1:80 [AP]
> GET /xcap-root/pres-rules/users/ibc(at)qwe/presrules HTTP/1.1
> Content-Length: 0
> X-Forwarded-For: 87.218.216.202  <--- ON TOP
> X-Forwarded-For: 1.2.3.4
> 
> 
> I'm used to SIP protocol in which there are scenarios with
> multiple proxies
> adding headers (as "Via" and "Record-Route" header). When a
> proxy adds a Via
> or Record-Route header it *must* write it on top of
> existing Via/Record-Route
> headers. I expect that in HTTP it should be the same as SIP
> is "based" on
> HTTP.
> 
> Regards.
> 
> 
> --
> Iñaki Baz Castillo <ibc(at)aliax.net>
> 
> --
> To unsubscribe send an email with subject unsubscribe to pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for
> questions.
> 


      

Saumil Shah wrote:
> Greetings,
> 
> The expected format for all XFF headers is that there's only ONE XFF
> header. Every proxy server appends the client IP to the end of the
> XFF IP list.

Not so!  RFC 2616, section 4.2 says:

Multiple message-header fields with the same field-name MAY be present 
in a message if and only if the entire field-value for that header field 
is defined as a comma-separated list [i.e., #(values)]. It MUST be 
possible to combine the multiple header fields into one "field-name: 
field-value" pair, without changing the semantics of the message, by 
appending each subsequent field-value to the first, each separated by a 
comma. The order in which header fields with the same field-name are 
received is therefore significant to the interpretation of the combined 
field value, and thus a proxy MUST NOT change the order of these field 
values when a message is forwarded.

So pound's implementation is in accordance with the standard.  Most 
webservers do the munge-to-one-field operation before log parsers or 
applications see it, so I don't think there's any issue.

Regards,
-- 
Dave Steinberg
http://www.geekisp.com/
http://www.steinbergcomputing.com/

2009/9/14 Dave Steinberg <dave(at)redterror.net>:
> Saumil Shah wrote:
>>
>> Greetings,
>>
>> The expected format for all XFF headers is that there's only ONE XFF
>> header. Every proxy server appends the client IP to the end of the
>> XFF IP list.
>
> Not so!  RFC 2616, section 4.2 says:
>
> Multiple message-header fields with the same field-name MAY be present in a
> message if and only if the entire field-value for that header field is
> defined as a comma-separated list [i.e., #(values)]. It MUST be possible to
> combine the multiple header fields into one "field-name: field-value" pair,
> without changing the semantics of the message, by appending each subsequent
> field-value to the first, each separated by a comma. The order in which
> header fields with the same field-name are received is therefore significant
> to the interpretation of the combined field value, and thus a proxy MUST NOT
> change the order of these field values when a message is forwarded.
>
> So pound's implementation is in accordance with the standard.  Most
> webservers do the munge-to-one-field operation before log parsers or
> applications see it, so I don't think there's any issue.

I really insist on the correct order of the values:

If a proxy inserts a *NEW* X-Forwarded-For header, this header must
appear in *top* of other existing X-Forwarded-For headers persent in
the received request. For sure this is the correct order.

Also, I expect that X-Forwarded-For header is not a standar header, so
its value it's not defined as a "comma-separated list".



-- 
Iñaki Baz Castillo
<ibc(at)aliax.net>

> I really insist on the correct order of the values:
> 
> If a proxy inserts a *NEW* X-Forwarded-For header, this header must
> appear in *top* of other existing X-Forwarded-For headers persent in
> the received request. For sure this is the correct order.

That seems intuitively correct, I agree.  However the wikipedia article 
says that the opposite is the way it is implemented:

http://en.wikipedia.org/wiki/X-Forwarded-For

> Also, I expect that X-Forwarded-For header is not a standar header, so
> its value it's not defined as a "comma-separated list".

The RFC just talks about general headers, i.e. standard and non-standard 
alike, so I think this applies here.  A CSL of IPs is the de-facto 
standard for this header.

Regards,
-- 
Dave Steinberg
http://www.geekisp.com/
http://www.steinbergcomputing.com/

2009/9/14 Dave Steinberg <dave(at)redterror.net>:
>> I really insist on the correct order of the values:
>>
>> If a proxy inserts a *NEW* X-Forwarded-For header, this header must
>> appear in *top* of other existing X-Forwarded-For headers persent in
>> the received request. For sure this is the correct order.
>
> That seems intuitively correct, I agree.  However the wikipedia article says
> that the opposite is the way it is implemented:
>
> http://en.wikipedia.org/wiki/X-Forwarded-For

You are right. However, it's the opposite of the standard behavior in
multivalue headers :(
IMHO a wrong de-facto standard.


-- 
Iñaki Baz Castillo
<ibc(at)aliax.net>