Re: [Zope-dev] [RFClet]: What about the request method and the client side trojan?

2002-04-16 Thread Florent Guillaume

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?

2002-04-15 Thread Toby Dickenson

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?

2002-04-12 Thread Toby Dickenson

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?

2002-04-12 Thread Florent Guillaume

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?

2002-04-12 Thread Oliver Bleutgen

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?

2002-04-12 Thread Oliver Bleutgen

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?

2002-04-11 Thread Toby Dickenson

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?

2002-04-11 Thread Casey Duncan

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?

2002-04-11 Thread Toby Dickenson

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?

2002-04-11 Thread Casey Duncan

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?

2002-04-11 Thread Oliver Bleutgen

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?

2002-04-11 Thread Lennart Regebro

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?

2002-04-11 Thread Toby Dickenson

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?

2002-04-11 Thread Oliver Bleutgen

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?

2002-04-11 Thread Toby Dickenson

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?

2002-04-10 Thread Toby Dickenson

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?

2002-04-10 Thread Lennart Regebro

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?

2002-04-10 Thread Brian Lloyd

  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?

2002-04-10 Thread Oliver Bleutgen

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?

2002-04-10 Thread Lennart Regebro

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?

2002-04-10 Thread Oliver Bleutgen

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: [Zope-dev] [RFClet]: What about the request method and the client side trojan?

2002-04-09 Thread Brian Lloyd

 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 )