As an aside, is anyone talking about seriously using this for access
control? We've established that using X-F-F is a bad idea for that, in
fact, I'd say that even known REMOTE_ADDR based auth is a bad idea, so
why does it matter whether it is "trustworthy"?

Anyway - I use X-F-F for IP geolocation, so I want the address to the
farthest left.

Just to illustrate the spoofing scenario: I sent X-Forwarded-For:
66.66.66.66 to my server (LB, then mod_proxy) so it receives the
following in the end: (unless configured to do otherwise)
X-Forwarded-For: 66.66.66.66, 24.152.161.x, 127.0.0.1
otherwise it would have resulted in X-Forwarded-For: 24.152.161.x,
127.0.0.1

Obviously IP geolocation is very unreliable, but I definitely want the
farthest left IP. If it's private, I still want it so I don't bother
to geolocate - because the geolocation will be worthless anyway as the
proxy is often located somewhere else entirely and I don't want to
show the user that incorrect location. Likewise, if it's faked, I
really don't care either.

If I wanted what my _proxy_ saw as the REMOTE_ADDR, then this
middleware would need to be implemented using the
x_forwarded_for.split(",")[-NUMBER_OF_TRUSTED_PROXY_SERVERS].strip()
method suggested by Leo.

After rethinking this, I believe the interpretation of this header is
very much application-specific, so I'd suggest something with the
following effect to maintain compatibility and satisfy those that want
the client to the farthest out LB/rev proxy:

def __init__(self):
        self.proxies = getattr(settings, 'NUM_TRUSTED_PROXIES', 0)

def process_request(self, request):
        try:
            real_ip = request.META['HTTP_X_FORWARDED_FOR']
        except KeyError:
            return None
        else:
           real_ip = real_ip.split(",")[-self.proxies].strip()
        request.META['REMOTE_ADDR'] = real_ip

~chris

On Sep 20, 4:08 pm, "Leo Soto M." <[EMAIL PROTECTED]> wrote:
> On 9/20/07, Deryck Hodge <[EMAIL PROTECTED]> wrote:
>
>
>
> > A quick Google search turns up that this is indeed easily configurable
> > for both Squid and mod_proxy and the defaults look sane.
>
> What are those defaults?.
>
> My google-foo is very low today, and I only arrived at the squid
> FAQ[1], which says "We must note that access controls based on this
> header are extremely weak and simple to fake. Anyone may hand-enter a
> request with any IP address whatsoever[...]".
>
> And the mod_proxy page dind't help either, it just says: "Be careful
> when using these headers on the origin server, since they will contain
> more than one (comma-separated) value if the original request already
> contained one of these headers."
>
> [1]http://wiki.squid-cache.org/SquidFaq/ConfiguringSquid#head-3518b69c63...
> [2]http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#x-headers
> --
> Leo Soto M.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to