Re: Support for X-HTTPD-FORWARDED-FOR Re: [Zope-dev] Speaking of 2.6...

2002-04-11 Thread Toby Dickenson

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

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

to

if request.has_key('HTTP_X_FORWARDED_FOR'):
   addr=request['HTTP_X_FORWARDED_FOR']
elif request.has_key('REMOTE_ADDR'):
   addr=request['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
X_FORWARDED_BY)

Have you considered this approach?


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

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']




Toby Dickenson
[EMAIL PROTECTED]


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Support for X-HTTPD-FORWARDED-FOR Re: [Zope-dev] Speaking of 2.6...

2002-04-10 Thread Jim Washington

Support for X-HTTPD-FORWARDED-FOR

Code for this is pretty simple:

modify 2 files, ZServer/medusa/http_server.py and 
lib/python/AccessControl/User.py

1.  To put the proxy-passed ip address in the zserver log,

Around line 269 in ZServer/medusa/http_server.py, add a method 
http_request::client_ip

def client_ip(self):
proxy_client = self.get_header('x-forwarded-for')
if proxy_client:
return proxy_client
else:
return self.channel.addr[0]

Then around line  294, change the statement that does logging to use the 
method.
self.channel.server.logger.log (
self.client_ip(),
' - %s [%s] %s %d %d %s %s\n' % (
name,
...

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

In lib/python/AccessControl/User.py, around line 1116,
change

if request.has_key('REMOTE_ADDR'):
   addr=request['REMOTE_ADDR']

to

if request.has_key('HTTP_X_FORWARDED_FOR'):
   addr=request['HTTP_X_FORWARDED_FOR']
elif request.has_key('REMOTE_ADDR'):
   addr=request['REMOTE_ADDR']

I do not believe this does anything to authentication that is not 
possible now regarding spoofed ip addresses, so probably not a major 
security headache.

Major possible problem I can think of:  I do not use ZEO, and have no 
idea what these changes might do there.  I do not have check-in 
privileges, and probably should not until I get a better clue of how cvs 
works :).

Anyway, here is the code FWIW.  Apologies that it is not a patch per se. 
 Now looking for a more clueful sponsor to take it from here to check-in 
(after vetting?)

-- Jim Washington

Brian Lloyd wrote:

...I sent out a note a while ago now trying to scare up 
some ideas on how to vet the current list of 2.6 proposals 
and get to a final plan. I didn't get much (any?) response :(

For a couple of things that were ready to go and fairly non
controversial (like Toby's unicode work), I put on the BDFL 
hat and said merge it!.

But there are still a lot of things on the proposed features 
that are undone, and some that are controversial enough that 
we need to get to closure on them.

I'll volunteer to convert the current proposed feature list 
into a draft plan, where the conversion boils down to 
adding some columns to the table:

Proposal - name and link to the proposal

Resources - who is working on it

Committed - Y/N whether the volunteers have committed to have
the implementation and docs done by the first week
in June. I'll fill in what I know has been committed
to, people can update this (or let me know and I'll 
do it), and anything that doesn't get a 'Y' in a 
reasonably short time will be put in the cooler.

Vetted - Y / N whether the community and / or the relevant BDFLs
 have come to some agreement on whether it *should* be 
 done. The list of items without a 'Y' will be our next 
 order of business. Getting to closure on those either 
 via the list, IRC, or whatever is the main block on the 
 critical path.

Status - Complete or incomplete 


I've taken a first stab at this. I've set the committed to 'Y' 
for those things that I know I've gotten commitments for. For 
those set to 'N', please let me know if you can commit to the 
date (or change it yourself in the wiki).

The updated plan is at:

http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures


Once we get the commitments up to date, we can start wrangling 
with the vetting...





___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: Support for X-HTTPD-FORWARDED-FOR Re: [Zope-dev] Speaking of 2.6...

2002-04-10 Thread Oliver Bleutgen

Jim Washington wrote:


 2.  If we want to get fancy about allowing authentication using that ip 
 address like naked ZServers can do,
 
 In lib/python/AccessControl/User.py, around line 1116,
 change
 
if request.has_key('REMOTE_ADDR'):
   addr=request['REMOTE_ADDR']
 
 to
 
 if request.has_key('HTTP_X_FORWARDED_FOR'):
   addr=request['HTTP_X_FORWARDED_FOR']
elif request.has_key('REMOTE_ADDR'):
   addr=request['REMOTE_ADDR']
 
 I do not believe this does anything to authentication that is not 
 possible now regarding spoofed ip addresses, so probably not a major 
 security headache.

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.

TCP spoofing OTOH is far more complicated, if (does it?) zope turns off 
the source routing option when replying, if present. IMO something like 
cracking a router or predicting sequence numbers is another level from 
adding a custom http-header.


cheers,
oliver



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: Support for X-HTTPD-FORWARDED-FOR Re: [Zope-dev] Speaking of 2.6...

2002-04-10 Thread Jim Penny

On Wed, Apr 10, 2002 at 06:59:38PM +0200, Oliver Bleutgen wrote:
 Jim Washington wrote:
 
 
 2.  If we want to get fancy about allowing authentication using that ip 
 address like naked ZServers can do,
 
 In lib/python/AccessControl/User.py, around line 1116,
 change
 
if request.has_key('REMOTE_ADDR'):
   addr=request['REMOTE_ADDR']
 
 to
 
 if request.has_key('HTTP_X_FORWARDED_FOR'):
   addr=request['HTTP_X_FORWARDED_FOR']
elif request.has_key('REMOTE_ADDR'):
   addr=request['REMOTE_ADDR']
 
 I do not believe this does anything to authentication that is not 
 possible now regarding spoofed ip addresses, so probably not a major 
 security headache.
 
 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 Penny

 
 TCP spoofing OTOH is far more complicated, if (does it?) zope turns off 
 the source routing option when replying, if present. IMO something like 
 cracking a router or predicting sequence numbers is another level from 
 adding a custom http-header.
 
 
 cheers,
 oliver
 
 
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )
 


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )