Re: [Zope-dev] [RFClet]: What about the request method and the client side trojan?
On Tue, 9 Apr 2002 13:17:40 -0400, "Brian Lloyd" <[EMAIL PROTECTED]> wrote: >> I think zope's management methods (the potentially destructive ones) and 'coonstructive' ones too >> should not accept REQUESTs with REQUEST_METHOD "GET". >This is hard, hard, problem. While some good ideas have been >proposed, there is not really a quick fix that doesn't have >some downside that some group somewhere considers a >showstopper :( I agree Olivers suggestion is not a total solution, but does it have a showstopper problem? 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 )
Re: [Zope-dev] [RFClet]: What about the request method and the client side trojan?
From: "Oliver Bleutgen" <[EMAIL PROTECTED]> > I think zope's management methods (the potentially destructive ones) > should not accept REQUESTs with REQUEST_METHOD "GET". Do you have any proposal for how to go about doing this? ___ 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: [Zope-Coders] Re: [Zope-dev] Speaking of 2.6...
> The idea is to allow user to specify several points of presence (pop) > for an object. Does this break security? Probably yes, but in what case? > If an object from higly secure envionment appeared somewhere in > Anonymous zone, what then? Yes, Anonymous is able to alter object. But > there was reason for that! Maybe - but maybe you just made the link without realizing the effect on security. That is one of the biggest conceptual problems here. Security behavior has to be as simple and understandable as possible for it to be useful. If people don't feel like they understand it, they will always have a nagging fear that they are vulnerable - and they will probably be right. One could argue that we are already pushing the boundaries with the current security implementation, which is why the bar is so high for adding things to the core that potentially make things more complex yet. > >Comparing it to Unix hard links is fine, but Unix doesn't > >use Acquisition to handle security, so the comparison is > >not apples-to-apples :) We need to spell out the exact semantics > >(*especially* wrt security, but also in terms of its effect on > >ZODB identity semantics, effects on undo, etc.) > > > Ok. I am not too well in English but I'll try to do my best. If it is > not hard for you give several words of explanation of "ZODB identity > semantics" and "effects on undo", not everything is clear for me. Undo uses the "place" of an object as part of the criteria for deciding whether you can undo changes to it. If the meaning of "place" changes, undo behavior is likely to change. To use your earlier example, now Anonymous users might be able to undo changes made by a manager (in a different "place" on the "same" object). Is this acceptable? I don't know, but before we think about allowing changes like this into the core, the differences in behavior need to be spelled out in detail with specific examples. Likewise with ZODB. What effects would links have on cache behavior (which are based on persistent identity)? On packing behavior? > Why we are not willing to allow such scenario? AFAIK there was and are a > lot of concernes refarding soft- and hardlinks in /tmp folder, with > sticky bit, etc... But they are usually solved with different means. > Yes, Zope and ZODB is much more complex. But why we have to limit > ourselves because something is difficult. I'm not trying to say that we shouldn't do something because it is difficult - just that in order to make changes like this we need to elaborate and understand all of the details and have a workable answer for all of the problems. > Why not mark the feature as > experimental (red button, a lot of warnings, for instance) and make it > available to SuperManager only ;) Because that's the textbook case for making it a Product :) We shouldn't be putting things in the core that come with flashing red warnings and can only be used by superusers. What is wrong with leaving this as an add-on product? Why does it _need_ to be a part of the core at all? Useful products are useful, whether or not they "come with Zope", and there are plenty of very useful products that don't come built in. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ 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: [Zope-Coders] Re: [Zope-dev] Speaking of 2.6...
On Wed, 10 Apr 2002 01:30:56 +0300, Myroslav Opyr <[EMAIL PROTECTED]> wrote: >Is Anonymous able to get out of the shared >object to secure environment? User X is designated as a manager of folder /Xfolder. In todays Zope /Xfolder is a secure environment He has no authority over objects outside that folder, thanks to aq_inContextOf Can he create links to objects outside that folder? Links would be pretty useless if not. A common use case would be to create a link /XFolder/banner.gif to /stock_images/banners/mono.gif (for example). However if that is allowed, he now has management rights over that image object. I dont see how 'hard links' can possibly avoid this problem. 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 )
Re: [Zope-Coders] Re: [Zope-dev] Speaking of 2.6...
At 01:30 10-04-2002 +0300, Myroslav Opyr wrote: >Ok. Let's find out what we have and what we want. First of all we have >strict hierarchy in ZODB where each object appears only once in the >tree. Thus to access to an object it is only one way from root down to >an object through containers. >The idea is to allow user to specify several points of presence (pop) >for an object. > Precisely. My first hack solves this and I've been using it OK in production sites. But I didnt like the fact that an object "point of presence" in the Zope tree was identical in every instance. That leads to confusion. My second hack creates a ProxyObject class thus allowing for a different metatype and a different icon. This reduces confusion. And you can also provide a management tab with links to the "original" object "point of presence". I tried using Python 2.1 Proxy classes but Acquisition wasnt "proxiable"... C U! -- MV ___ 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: [Zope-Coders] Re: [Zope-dev] Speaking of 2.6...
At 14:38 09-04-2002 -0400, Brian Lloyd wrote: >> As in Unix, a hard link has different semantics from a soft link. I'm >> thinking of the "hard link" semantics. > >Comparing it to Unix hard links is fine, but Unix doesn't >use Acquisition to handle security, so the comparison is >not apples-to-apples :) > No its not, agreed. But actually, when you create a hard link to an executable file and from within that executable request the path, you'll get different paths. Crappy way of doing security, but there's lots of people doing it :-) I guess you could call that acquisition :-) >Security in particular is very concerned with *containment* >path (rather than just acquisition path) in order to prevent >"stealing" access through acquisition wrappers. Having objects >with more than one "place" may introduce much the same problem, >so we'll need to write up in detail the effects on the security >machinery or its application to domain objects (or if the security >machinery does not need to change, we need to spell out why). > I wouldnt mind doing this, but I think its out of my league C U! -- MV ___ 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: [Zope-Coders] Re: [Zope-dev] Speaking of 2.6...
At 10:06 10-04-2002 -0400, Brian Lloyd wrote: >What is wrong with leaving this as an add-on product? Why does >it _need_ to be a part of the core at all? Useful products are >useful, whether or not they "come with Zope", and there are >plenty of very useful products that don't come built in. > I totally agree. Thats what I previously thought was the case: that your earlier comments were very much towards the "links" stuff being "Vetted" and that it should be released as a patch/product. C U! -- MV ___ 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: [Zope-Coders] Re: [Zope-dev] Speaking of 2.6...
At 15:12 10-04-2002 +0100, Toby Dickenson wrote: >User X is designated as a manager of folder /Xfolder. In todays Zope >/Xfolder is a secure environment He has no authority over objects >outside that folder, thanks to aq_inContextOf > >Can he create links to objects outside that folder? > No, he cant. To create a link (my hack...) you first need to obtain the object reference (moniker) with a Copy operation so that you can then do a "Paste Ref." operation. >Links would be pretty useless if not. > No they wouldnt. >A common use case would be to >create a link /XFolder/banner.gif to /stock_images/banners/mono.gif >(for example). > >However if that is allowed, he now has management rights over that >image object. > >I dont see how 'hard links' can possibly avoid this problem. > Right. But they would be useful to put an image in /Xfolder/images/ and then be able to paste links to it into /Xfolder/layout1/ and /Xfolder/layout2/ and /Xfolder/Development without the need to create multiples instances of the same image or without coding multiple requests for that object. C U! -- MV ___ 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: [Zope-dev] [RFClet]: What about the request method and the client side trojan?
> >> should not accept REQUESTs with REQUEST_METHOD "GET". > > >This is hard, hard, problem. While some good ideas have been > >proposed, there is not really a quick fix that doesn't have > >some downside that some group somewhere considers a > >showstopper :( > > I agree Olivers suggestion is not a total solution, but does it have a > showstopper problem? Only if you happen to have an application deployed and might ever want to upgrade your Zope installation without having to do a total code audit :^) Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ 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...
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: [Zope-dev] [RFClet]: What about the request method and the client side trojan?
Lennart Regebro wrote: > From: "Oliver Bleutgen" <[EMAIL PROTECTED]> > >>I think zope's management methods (the potentially destructive ones) >>should not accept REQUESTs with REQUEST_METHOD "GET". >> > > Do you have any proposal for how to go about doing this? Well, I don't see how one could do that systematically, by what I mean doing it on a single point and be done for all methods. I am not too intimate with the deeper innards of zope (ZPublisher & ZODB etc.), but I suspect it would be nearly impossible to decide, in a sane way, what would constitute an active (i.e. destructive or constructve) method. A method that causes a write to the ZODB? No, that wouldn't fly. I was thinking more of something like adding the checks individually to each method in stock zope for which it is appropriate. Brian is of course right in his other mail by stating that this might and will break custom products which use the wrong method, but I wouldn't call a global s/method='GET'/method='POST'/g ( SCNR ;-) ) a code audit. It might be also made customizable via a command line switch to z2.py in the beginning, with default to off. 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: [Zope-dev] [RFClet]: What about the request method and the client side trojan?
From: "Oliver Bleutgen" <[EMAIL PROTECTED]> > I was thinking more of something like adding the checks individually to > each method in stock zope for which it is appropriate. > > Brian is of course right in his other mail by stating that this might > and will break custom products which use the wrong method, but I > wouldn't call a global s/method='GET'/method='POST'/g ( SCNR ;-) ) a > code audit. It might be also made customizable via a command line switch > to z2.py in the beginning, with default to off. This would be a huge task. My gut feeling is that it is a lot of work for very little benefit, although I don't really have any arguments to back that up with. ___ 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...
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: [Zope-dev] [RFClet]: What about the request method and the client side trojan?
Lennart Regebro wrote: > From: "Oliver Bleutgen" <[EMAIL PROTECTED]> > >>I was thinking more of something like adding the checks individually to >>each method in stock zope for which it is appropriate. >> >>Brian is of course right in his other mail by stating that this might >>and will break custom products which use the wrong method, but I >>wouldn't call a global s/method='GET'/method='POST'/g ( SCNR ;-) ) a >>code audit. It might be also made customizable via a command line switch >>to z2.py in the beginning, with default to off. >> > > This would be a huge task. My gut feeling is that it is a lot of work for > very little benefit, although I don't really have any arguments to back that > up with. Would it really be a huge task? Wouldn't we just have to find all methods which are callable through the web and add two maybe three identical lines of code right at the beginning? Something like (sorry for the wrapping) if REQUEST and REQUEST.has_key('REQUEST_METHOD') and REQUEST['REQUEST_METHOD'] != 'POST': raise APPROPRIATE_ERROR, "Appropriate message" 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...
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 )
Re: Support for X-HTTPD-FORWARDED-FOR Re: [Zope-dev] Speaking of2.6...
> > >>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... Regards, -- Jim Washington ___ 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 )