Re: [Zope-dev] [RFClet]: What about the request method and the client side trojan?
Oliver Bleutgen [EMAIL PROTECTED] wrote: Although I repeat myself, implementing this proposal would give me a lot of options to prevent myself from this kind of attack, completely or partially. - In Internet Explorer I can disable javascript. (problem solved) - In Internet Explorer I use the zone restrictions (prevents attacks from untrusted servers) - I can do the same in mozilla - additionally, in mozilla I can just disable form submitting in javascript, with something like (this is surely wrong) user_pref(capability.policy.default.HTMLFormElement.submit, noAccess); Put this your prefs.js file and you are done. Really, it _would_ help. Okay, I agree that it does indeed help. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[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?
On Friday 12 Apr 2002 7:19 pm, Jeffrey P Shell wrote: that your proposal isn't up there (or the catalog is up to its old charms ;) No, its not up there. But now, does this mean I have to go through and tag every method that might cause a state change? Or might not? You wont ever *have* to do anything to your own methods. You might *want* to, if you want the extra protection against client side trojans that this declaration will give. Now that I'm understanding things more, I never call non-idempotent methods (I hope I'm using that term right) from DTML anymore Me to. Thats why I was suprised to see the opposition. Overall, I still don't know how I feel about the whole thing. It's good to have Zope as secure as possible, but if putting that security makes it suddenly much harder to develop for or upgrade to/for, I worry about the support costs involved. Indeed. ___ 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?
On Thursday 11 April 2002 6:37 pm, Jeffrey P Shell wrote: On 4/11/02 7:55 AM, Toby Dickenson [EMAIL PROTECTED] Then you're lucky. Usually, any time I see dtml-var someNonIdempotentMethod(), I immediately change it to the name lookup call. Don't blame me, I've been following this paradigm for years (since before there were expr's in DTML). I would hate to have to special case those methods OK, that kills the second half of my proposal. (I still think your style is bizarre though ;-) (which I use a lot, usually as accessors, ie: def Summary(self): return self.title + self._description ). Aha! maybe not! That example method definitely is idempotent. Under my proposal it should not be declared non-idempotent, and would not have restricted dtml-name-lookup semantics. I agree being able to write dtml-var Summary is a good thing whether Summary is an attribute or method (and not at all bizarre). I agree that changing this would be disasterous. Im not sure whether you misunderstood the proposal, or just gave a poor example to explain why you thought the proposal is bad. My proposal only affects method which have been declared to be non-idempotent. This declaration would only be added to methods that change externally visible state (in ZODB, Filesystem etc) or have external side effects (such as sending an email) Here is a differnet example. Suppose you write a method: def setEmptyTitle(self): self.title = 'empty' How would you call it from dtml. I think the 'right' answer is that you generally wouldnt call this method from dtml. From a PythonScript maybe, but not dtml. However if you did call if from dtml, would you still be using the name-lookup form, such as: dtml-var setEmptyTitle or would you use dtml-call setEmptyTitle dtml-call setEmptyTitle() dtml-var setEmptyTitle() ? (Im not going to argue that anyone is 'wrong' to prefer the first form in this case. Its my *personal* preference that calling non-idempotent methods using the name-lookup form should be caught and reported as an error I am wondering whether this preference is shared.) ___ 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?
Oliver Bleutgen [EMAIL PROTECTED] wrote: The issue of client side trojan recently came to my mind again. [..] I think zope's management methods (the potentially destructive ones) should not accept REQUESTs with REQUEST_METHOD GET. I like the idea of trying to secure that kind of things a lot. Unfortunately, considering how trivial it is for Javascript code to do a POST programmatically, I don't see how that proposal would actually help. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[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?
Florent Guillaume wrote: Oliver Bleutgen [EMAIL PROTECTED] wrote: The issue of client side trojan recently came to my mind again. [..] I think zope's management methods (the potentially destructive ones) should not accept REQUESTs with REQUEST_METHOD GET. I like the idea of trying to secure that kind of things a lot. Unfortunately, considering how trivial it is for Javascript code to do a POST programmatically, I don't see how that proposal would actually help. Although I repeat myself, implementing this proposal would give me a lot of options to prevent myself from this kind of attack, completely or partially. - In Internet Explorer I can disable javascript. (problem solved) - In Internet Explorer I use the zone restrictions (prevents attacks from untrusted servers) - I can do the same in mozilla - additionally, in mozilla I can just disable form submitting in javascript, with something like (this is surely wrong) user_pref(capability.policy.default.HTMLFormElement.submit, noAccess); Put this your prefs.js file and you are done. Really, it _would_ help. 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?
Jeffrey P Shell wrote: I have to now admit to not having seen the proposal, I've just been following along here and struggling to capture the meaning of idempotent as it applies to Zope security, but I *think* I'm starting to grok it. Since a search for idempotent on zope.org yields no results, I'm assuming that your proposal isn't up there (or the catalog is up to its old charms ;) Jeffrey, idempotence is mentioned about in the http/1.1 rfc, which says Methods may also have the property of idempotence in that (aside from error or expiration issues) the side-effects of N 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. There's another quote from the rfc in my posting which started this thread. The question is, to put it bluntly, if e.g. something img src=http://yourserver/manage_delObjects?ids:list=an_object; anywhere on any page you might visit should be able to do what it does now, if you happen to be authorized at yourserver with enough priviledges. The fix would be to not accept GET requests for certain methods. 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?
On Wednesday 10 April 2002 5:07 pm, Brian Lloyd wrote:
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 :^)
OK, heres a more specific proposal:
1. Add a method to ClassSecurityInfo declareNonIdempotent('methodName')
2. Add this declaration to ZMI methods which create, delete, or change
content. (It also needs to get added to object constructors, but not the
pre-constructor form. Im not sure exactly how to do that yet)
3. Change ZPublisher to not allow GET requests on non-idempotent methods.
(This probably affects DAV and FTP too)
4. Change dtml to not allow dtml-var someNonIdempotentMethod, although it
should still allow dtml-var someNonIdempotentMethod()
How many problems would this cause.
a. It affects anywhere in the ZMI which currently use GET when they should be
using POST. I suspect we would already know about such cases, because it
would also cause problems when accessing the ZMI through a cache.
b. It affects any pages in other products that link to the ZMI using GET
reqests. In a quick audit of my server logs I see I am doing this at least
once; I have a script that uses a GET request to restart the server.
c. It affects code that uses dtml-var someNonIdempotentMethod to call a
method with no parameters. I have no idea how common that would be.
On balance, I think it might be worth building a prototype.
___
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?
Toby Dickenson wrote: [snip] 4. Change dtml to not allow dtml-var someNonIdempotentMethod, although it should still allow dtml-var someNonIdempotentMethod() Ahhh! How do you propose to do that? I see a lot of bruised foreheads resulting from this... How many problems would this cause. [snip] c. It affects code that uses dtml-var someNonIdempotentMethod to call a method with no parameters. I have no idea how common that would be. Likely very common. On balance, I think it might be worth building a prototype. Best of luck to you. -Casey ___ 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?
dtml-var foo is not even close to the equivilant of dtml-var foo() The former uses mapply to comb the namespace for arguments and maps them to the callable and then calls it (if it is a callable, that is). IOW foo could have any number of arguments. The latter always calls foo with no argument. My point is how do you disinguish dtml-var foo meaning Call foo passing everything from the namespace that maps to an arg from dtml-var foo meaning Call foo passing everything, but foo doesn't use anything from dtml-var foo Call foo and foo takes no arguments from dtml-var foo foo is not callable, so return the value of foo. The most troublesome case is where foo accepts any number of arguments (such as a DTML method or ZPT or any other method with **kw), and you cannot know whether it changes objects or simply returns some string or something. I don't think it is helpful to assume that because a method takes arguments, it is dangerous. I can write destructive methods that take no arguments too. Also, are we talking about only fixing the action on GET for the ZMI or for all Zope apps? If the answer is Just the ZMI then we are talking about doing something that has not been done before: Making the ZMI different from all other Zope apps. If the answer is All Zope Apps then I fear you have just broken every Zope app I have ever seen 8^). If I were to implement this, a very simple approach seems attractive: Lock the ZODB on GET requests so that no transactions can be committed. However, I'm not sure I want to go there. -Casey Toby Dickenson wrote: On Thursday 11 April 2002 4:39 pm, Casey Duncan wrote: Toby Dickenson wrote: [snip] 4. Change dtml to not allow dtml-var someNonIdempotentMethod, although it should still allow dtml-var someNonIdempotentMethod() Ahhh! How do you propose to do that? I see a lot of bruised foreheads resulting from this... Really? dtml-var someNonIdempotentMethod only works with methods that take zero parameters (excluding self). The question is: how many zero parameter non-idempotent methods are there? I have only been able to find one such method in the current Zope cvs, and I get similarly optimistic results in my products. Likely very common. So far I have only been checking with crude greps, so I could be wrong. Any chance you could spend a couple of minutes looking for an example to share? ___ 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?
First, Toby, thanks for that proposal, it's indeed far more elegant than the mess I had in mind. Casey Duncan wrote: Toby Dickenson wrote: [snip] 4. Change dtml to not allow dtml-var someNonIdempotentMethod, although it should still allow dtml-var someNonIdempotentMethod() Ahhh! How do you propose to do that? I see a lot of bruised foreheads resulting from this... Maybe we don't need that point, because methods declared nonIdemPotent (maybe we should call it disallowGET?) would fail anyway if they had been passed the original REQUEST. How many problems would this cause. [snip] c. It affects code that uses dtml-var someNonIdempotentMethod to call a method with no parameters. I have no idea how common that would be. Likely very common. Are you sure? But anyway, this checking also could be disabled (or - upgrade path friendlier - enabled) by a command line switch (or a config file). Anybody could check their own Sites/Products just by enabling the checking. I for one would consider it a bug if my application failed with a zope behaving like the authors of the http rfc are recommending. On balance, I think it might be worth building a prototype. Best of luck to you. My personal opinion is that it might be ugly and potentially cause problems with the upgrade path now, it will get even worse the more features zope gets. I suspect the question of the request method will get more important, as more and more protocols use HTTP as a transport. So perhaps at least the first point of toby's proposal - or something functionally equivalent - could be implemented (adding this method to ClassSecurityInfo), which wouldn't hurt anyone, but give application writers the chance to use this feature. cheers, olive ___ 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: Casey Duncan [EMAIL PROTECTED] My point is how do you disinguish dtml-var foo meaning Call foo passing everything from the namespace that maps to an arg from dtml-var foo meaning Call foo passing everything, but foo doesn't use anything from dtml-var foo Call foo and foo takes no arguments from dtml-var foo foo is not callable, so return the value of foo. My point is: Why on earth would you do that? I don't see how preventing the calling of dtml-var foo but allowing dtml-var foo() would have any significant positive contribution, (except possibly clarity). Also, are we talking about only fixing the action on GET for the ZMI or for all Zope apps? If the answer is Just the ZMI then we are talking about doing something that has not been done before: Making the ZMI different from all other Zope apps. If the answer is All Zope Apps then I fear you have just broken every Zope app I have ever seen 8^). Well, I don't think I have ever used a GET to call a destructive parameter in any application, but I can see that it is practical. What I have done though, is to call it manually to do things when I have messed up. :-) If I were to implement this, a very simple approach seems attractive: Lock the ZODB on GET requests so that no transactions can be committed. However, I'm not sure I want to go there. I'm sure I don't. :-) I just keep thinking there has to be a better way. I haven't figured out what yet, though. :-) Normally you would pop up a confirmation before taking destructive actions, but I don't see how that is possible via a web interface. This is something I really hate with the web. Every advancement that had been done in making user interfaces consistent and usable was thrown out the window. And I blame Netscape. The bastards. ___ 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?
On Thursday 11 April 2002 5:16 pm, Casey Duncan wrote: The most troublesome case is where foo accepts any number of arguments (such as a DTML method or ZPT or any other method with **kw), and you cannot know whether it changes objects or simply returns some string or something. Yes, that is a limitation of my proposal. It doesnt cover non-idempotent DTML and ZPT. (DTML and ZPT is idempotent by definition when used for presentation logic.) I dont think that limitation is fatal. I don't think it is helpful to assume that because a method takes arguments, it is dangerous. I can write destructive methods that take no arguments too. Sure you could. Lets assume you have, and have declared it non-idempotent as described in my proposal. Firstly, you would not be calling it from DTML or ZPT if you were using those only for presentation logic. presentation logic by definition cant be destructive. Anyway, even if you were writing a destructive DTML method, I bet you would write it as one of: dtml-call my_destructive_method dtml-call my_destructive_method() dtml-var my_destructive_method() dtml-in my_destructive_method() dtml-with my_destructive_method() but not: dtml-var my_destructive_method dtml-in my_destructive_method dtml-with my_destructive_method Those last three forms are today legal. My proposal would make them an error, but only because your new destrucive method has been declared non-idempotent. I think thats an improvement, but only a slight one. It is much less important than Oliver's original proposal which was to control methods called by ZPublisher, not by DTML. I would be happy to go with a reduced proposal that leaves DTML unchanged, and made it an error to issue a GET request for http://host/path/my_destructive_method (but only because my_destrucive_method has been declared non-idempotent) Also, are we talking about only fixing the action on GET for the ZMI or for all Zope apps? Much like when new style security declaration were introduced. Initially only ZMI had them, but new products could use them too. If I were to implement this, a very simple approach seems attractive: Lock the ZODB on GET requests so that no transactions can be committed. However, I'm not sure I want to go there. H. I wonder whether read-only transactions could be the basis for a ZODB optimisation... ___ 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?
Casey Duncan wrote: [SNIP] Also, are we talking about only fixing the action on GET for the ZMI or for all Zope apps? If the answer is Just the ZMI then we are talking about doing something that has not been done before: Making the ZMI different from all other Zope apps. If the answer is All Zope Apps then I fear you have just broken every Zope app I have ever seen 8^). But as I read here it is planned for Zope3 to change the ZMI anyway, which will at least break the lookfeel of any zope app which integrates with the ZMI, and therefore will make the ZMI different from zope apps. I guess there might be more breakage. So sometime in the future application writers will have to upgrade their apps anyway. And Tob As I understand Toby's proposal, you have to explicitly declare if your method can only be invoked via POST, not the other way around. So it's optional for the applications, as long as they don't pass the GET-polluted REQUEST to ZMI methods. If I were to implement this, a very simple approach seems attractive: Lock the ZODB on GET requests so that no transactions can be committed. However, I'm not sure I want to go there. No, I would like the application writer to be able to write unsafe methods. It's also quite a mess today (at least IMO) how version cookies are capable of messing around with the ZODB in suprising and (IMO) unwanted ways. I may have some strong feelings about this security stuff, but it's not too hard to give a scenario where zope's promiscuity in this respect can have really ugly effects - and it doesn't need much imagination. With the implementation of Toby's proposal (barring the dtml-var thing, which isn't needed for that, as far as I see), one could at least be secure when javascript is disabled. Maybe browser writers one day will wake up and also follow the recommendations of the rfc, then zope will be there already. Ok, my knowledge of zope's innards stops quite before ZPublisher comes into play, not to talk about Zope 3, but I'm willing to offer help where it's possible. What can I do now? 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?
On Thu, 11 Apr 2002 18:53:54 +0200, Oliver Bleutgen [EMAIL PROTECTED] wrote: With the implementation of Toby's proposal (barring the dtml-var thing, which isn't needed for that, as far as I see) Correct. The dtml-var change only helps guard against a careless dtml/zpt author reopening the same hole. 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?
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-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 )
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: [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 )
[Zope-dev] [RFClet]: What about the request method and the client side trojan?
The issue of client side trojan recently came to my mind again. Looking at http://www.zope.org//Members/jim/ZopeSecurity/ClientSideTrojan I found nothing new since Oct. 2001, so I thought I bring up the issue again, maybe it's something which could be taken care of for zope = 2.6. I wrote something about that at the wiki, but let me repeat my proposal. I think zope's management methods (the potentially destructive ones) should not accept REQUESTs with REQUEST_METHOD GET. This is in accordance with the http/1.1 rfc (reposted from the wiki): Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others. In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered safe. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. The win would be that disabling javascipt would make a client save from this form of attack, AFAIK, OTOH I can't think of anything which would break ATM. 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?
The issue of client side trojan recently came to my mind again. Looking at http://www.zope.org//Members/jim/ZopeSecurity/ClientSideTrojan I found nothing new since Oct. 2001, so I thought I bring up the issue again, maybe it's something which could be taken care of for zope = 2.6. I wrote something about that at the wiki, but let me repeat my proposal. I think zope's management methods (the potentially destructive ones) should not accept REQUESTs with REQUEST_METHOD GET. This is in accordance with the http/1.1 rfc (reposted from the wiki): snip RFC citation... The win would be that disabling javascipt would make a client save from this form of attack, AFAIK, OTOH I can't think of anything which would break ATM. While I don't necessarily disagree about making GETs idempotent, this still doesn't make you safe, even with JS turned off. A quick example: images can be used as form submit buttons. If I can get you to visit a page and click on my innocent looking image... you're done :) 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 :( 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 )
