[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
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 brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Brian Lloyd wrote:
[proposal of dissallowing GETs for management methods] 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.
Ahh, idempotent, that word escaped me ;-).
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 :)
Ok, I wasn't clear enough. What I proposed would at least give the browser implementors a chance to remedy the problem (e.g. ask before form submission etc.). Compare your scenario to that where one just needs to write <img href="http://victimserver/evilmethod">
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 consider what I wrote really not the most sophisticated idea around, more something in the line of disabling unneeded servers on a unix machine. But I also don't see how it could be a showstopper for any scenario. No pain (barring modification of methods, which could be done step by step), some gain ... sounds good to me. cheers, oliver
On Tue, 9 Apr 2002 13:17:40 -0400, "Brian Lloyd" <brian@zope.com> 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 tdickenson@geminidataloggers.com
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 brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
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.
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
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?
<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?
From: "Casey Duncan" <casey@zope.com>
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.
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.
Hmmmm. I wonder whether read-only transactions could be the basis for a ZODB optimisation.......
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 look&feel 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
On Thu, 11 Apr 2002 18:53:54 +0200, Oliver Bleutgen <myzope@gmx.net> 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 tdickenson@geminidataloggers.com
On 4/11/02 7:55 AM, "Toby Dickenson" <tdickenson@geminidataloggers.com> 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.
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 (which I use a lot, usually as accessors, ie: def Summary(self): return self.title + self._description ). A powerful feature of classic (pre-expr) DTML was the fact that you could just use a name, and you didn't have to worry about whether <!--#var Summary--> was a method or an attribute. For people who have lots of DTML and Python code based upon these assumptions, mass-breakage upon upgrading would be a huge detractor against upgrading. It's hard enough to move some of our sites from Zope 2.3.3 to 2.5 or even 2.4.x. -- Jeffrey P Shell www.cuemedia.com
On Thursday 11 April 2002 6:37 pm, Jeffrey P Shell wrote:
On 4/11/02 7:55 AM, "Toby Dickenson" <tdickenson@geminidataloggers.com>
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.)
On 4/12/02 2:49 AM, "Toby Dickenson" <tdickenson@geminidataloggers.com> wrote:
On Thursday 11 April 2002 6:37 pm, Jeffrey P Shell wrote:
On 4/11/02 7:55 AM, "Toby Dickenson" <tdickenson@geminidataloggers.com>
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 ;-)
Personally, I absolutely abhor the difference between <dtml-var foo> And <dtml-far "foo"> It's violently non-obvious and confusing, even to seasoned Zope developers just glancing over code. So, personally, my bizarre style is to always explicitly say 'expr="..."', but I try to avoid expr's where necessary to make life simpler. Fortunately, there's the happy land of TAL and TALES for me to play in these days. :)
(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.
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 ;) But now, does this mean I have to go through and tag every method that might cause a state change? Or might not?
Im not sure whether you misunderstood the proposal, or just gave a poor example to explain why you thought the proposal is bad.....
Since I haven't read the proposal, only the recent mail messages, I'm just trying to get clearer understanding. Maybe I'm just having the same sort of trouble with idempotent versus nonidempotent that I did with mutable and immutable (for some reason, I unlearned the differences between the two between CS and the real world, and invented new meanings around the word 'mute' instead of 'mutate').
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.)
I think that it could be caught and reported as a Warning, but not an error. It's been a common thing for a long time, and I think it would be bad to label it as an "error". Warn first, slap later. :) Now that I'm understanding things more, I never call non-idempotent methods (I hope I'm using that term right) from DTML anymore, and when I did it was always with a <dtml-call expr="...">, with rare uses of direct name use (<dtml-call ...>), usually in regards to SQL methods. So, it was my misunderstanding of the proposal. 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. -- Jeffrey P Shell www.cuemedia.com
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
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.
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
From: "Oliver Bleutgen" <myzope@gmx.net>
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?
Lennart Regebro wrote:
From: "Oliver Bleutgen" <myzope@gmx.net>
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
From: "Oliver Bleutgen" <myzope@gmx.net>
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.
Lennart Regebro wrote:
From: "Oliver Bleutgen" <myzope@gmx.net>
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
Oliver Bleutgen <myzope@gmx.net> 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:fg@nuxeo.com
Florent Guillaume wrote:
Oliver Bleutgen <myzope@gmx.net> 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
Oliver Bleutgen <myzope@gmx.net> 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:fg@nuxeo.com
participants (8)
-
Brian Lloyd -
Casey Duncan -
Florent Guillaume -
Jeffrey P Shell -
Lennart Regebro -
Oliver Bleutgen -
Toby Dickenson -
Toby Dickenson