Re: Support for X-HTTPD-FORWARDED-FOR Re: [Zope-dev] Speaking of2.6...

2002-04-11 Thread Jim Washington

Toby Dickenson wrote:

On Wed, 10 Apr 2002 12:16:35 -0400, Jim Washington [EMAIL PROTECTED]

2.  If we want to get fancy about allowing authentication using that ip 
address like naked ZServers can do,


if request.has_key('HTTP_X_FORWARDED_FOR'):
   elif request.has_key('REMOTE_ADDR'):

There are lots of things that use REMOTE_ADDR, and I guess they should
*all* use the proxy supplied address rather than the address of the
proxy. It makes sense to me that we should *replace* REMOTE_ADDR with
HTTP_X_FORWARDED_FOR at the earliest opportunity. (and create a

Have you considered this approach?

Not yet, but I like the idea...  As with Oliver's reply, this I think 
would need some research.  I will be refining what I mean by support 
in the subject line shortly.

On Wed, 10 Apr 2002 18:59:38 +0200, Oliver Bleutgen [EMAIL PROTECTED]

Correct me if I'm wrong, but this IMO makes spoofing against a naked 
ZServer a childs play.

Thats correct for a naked ZServer, or if behind a proxy which does not
sanitize the X-FORWARDED-FOR header. However it is safe if the request
comes from the right kind of proxy.

I think we need a new command line option to specify a list of IP
addresses which are trusted to run 'the right kind of proxy'. Zope
should only trust the X-FORWARDED-FOR header if the remote address is
one of its trusted proxies.

Pseudocode for handling this would be:

if request['REMOTE_ADDR'] in our_trusted_front_end_proxies:
request['HTTP_X_FORWARDED_BY'] = request['REMOTE_ADDR']
request['REMOTE_ADDR'] = request['HTTP_X_FORWARDED_FOR']

Excellent!  Except for command-line bloat.  With Matt Behrens's config 
this nevertheless could be workable.  Things are looking up.  Maybe. 
 U..., more research...

-- Jim Washington

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: Support for X-HTTPD-FORWARDED-FOR Re: [Zope-dev] Speaking of2.6...

2002-04-10 Thread Jim Washington

Correct me if I'm wrong, but this IMO makes spoofing against a naked 
ZServer a childs play. It's just adding a custom header to the request.
I also doubt that every reverse proxy overwrites this header, so 
zservers behind a proxy might also be hit.

Note:  this is using another web server to front for zope.  It turns out
to be fairly safe -- I have used a variant for quite a while and did
quite a bit of testing.  For short hand, I am going to call the other web
server apache.  Apache presumably uses something like getpeername to
fill in its idea of HTTP_X_FORWARDED_FOR or REMOTE_ADDR.  If the remote
user attempts to spoof it (by using hidden variables, or other HTTP
based techniques), the Zope server interprets this is a list, rather
than the expected string.  This is easy to detect, and in fact, if you
fail to handle it, you will probably simply error out.

If the attacker is using TCP spoofing, there is really not much you can
do at an application level.

On the other hand, I am now conviced that this is not an intelligent
thing to do, not even for presentation.  You already have Apache in
front, so why not use rewriting rules to make the URL distinguishable.
In this way, you can use one of the BASE or URL variables to determine
how the person got in.  This gives you pretty much the same level of
control (especially if you are worried only about internal/external) as
using IP addresses, without modifying either Zope or Apache.

Jim, Oliver

Thanks. I'm glad we have smart and knowledgeable people available to 
discuss these kinds of things.  My hope was that I could restrict my 
Manager account to a short list of machines, even through a squid or 
apache proxy.  Essentially add a third thing to have besides username 
and password.  Which I still think is better than just username and 
password, since Zope sees only *one* ip address coming from squid in the 
current situation.  I'll have to do some more thinking...


-- Jim Washington

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )