zope needs webdav global access *ON/OFF* feature
Hi all, I think zope MUST have a way to disable webdav access. Running a webdav client on some zope sites I found in almost all of them things like test_html index_html_old and some other forgiven methods that programmers leave on their applications. Depending on what test programmers were doing in this methods one could find a way to do some DOS on does sites, just to begin. I mean, even if the user dont have permissions to edit/save methods, just the fact that he is browsing my structure and viewing my methods is bad for security. I looked at source and the webdav implementation is class specific implemented, i.e, only objects of classes that import webdav stuff and implement it are Published by zope to a webdav client. I tryed to find a *central* switch to disable it on ZServer or ZPublisher, but no luck. I also tryed to find something like domain restriction which could be another way to disable webdav. The solution of disable Access Contents Information to anonymous isnt pratical on a complex site already in production. I'll try to find a way to disable/restrict the webdav access. Any suggestion? Best Regards, Júlio Dinis Silva _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.
JXlio Dinis Silva wrote:
I think zope MUST have a way to disable webdav access. Running a webdav client on some zope sites I found in almost all of them things like test_html index_html_old and some other forgiven methods that programmers leave on their applications. Depending on what test programmers were doing in this methods one could find a way to do some DOS on does sites, just to begin.
Yes, your fears are valid, but WebDAV really isn't the problem. Zope, at a deeper level, is what is causing your problem. You can find out the above information using any web browser, try this: http://www.cbsnewyork.com/objectIds I see they haven't deleted the QuickStart. Interesting... As you point out, once you know the names of methods and the like (see http://www.cbsnewyork.com/objectValues to find out what type objects are, funny... objectItems, which would be slightly more useful, isn't actually URL traversable...), you can do DOS attacks... more interestingly, if you find a method that is anonymously accessible but with some cool proxy roles (maybe because it needs to be like that), you can see if you can cause bad things to happen (like deleting data) by passing in interesting parameters (remember, Zope handily pops the traceback in the response, even in production mode, so you can tell what parameter you left out ;-) Anyway, enough of the problem... possible solutions: 1. Hack the Zope code so the traceback isn't appended to your HTML in production mode 2. Give anything you don't want to be traversable a prefix like i_ and then use Apache to screen these out, along with */manage*. 3. Setup a decent firewall to prevent XML-RPC, FTP and WebDAV access to your Zope server, except by people you trust. It's a hard problem to solve, made harder by the fact that Zope supports loads of protocols and is totally manageable through the web. These are Zope's strengths, but they do raise itneresting problems :-S cheers, Chris
Yes, your fears are valid, but WebDAV really isn't the problem. Zope, at a deeper level, is what is causing your problem. You can find out the above information using any web browser, try this:
http://www.cbsnewyork.com/objectIds
I see they haven't deleted the QuickStart. Interesting... As you point out, once you know the names of methods and the like (see http://www.cbsnewyork.com/objectValues to find out what type objects [--8<--snip] It's a hard problem to solve, made harder by the fact that Zope supports loads of protocols and is totally manageable through the web. These are Zope's strengths, but they do raise interesting problems :-S
This reveals a fascinating double-edged sword. It also makes for a very good way to explore what Zope really is and does. It would be cool if someone could set up a small Zopesite pro-actively, to demonsrte and explain this stuff better. Also me think that the security issues coul be addressed by having securebot DTMLmtehod which could go through the site, sniffing out stuff fed it by a template page and assigning come other role or settign preoperties to allow stronger filtering of requests on a folder scale. Maybe this is impossible due the reverse- peverse catch-22 nature of 'acquisition'. But surely one could use acqusition to insitute an even higher level method which would check any requests say which do not come from that local or specified IP/domain ? any thoughts? - Jason
Chris Withers wrote:
It's a hard problem to solve, made harder by the fact that Zope supports loads of protocols and is totally manageable through the web. These are Zope's strengths, but they do raise itneresting problems :-S
It would be nice to have "security by default". This is the same problem that's really annoying with most Linux distributions. I'd prefer to see a more OpenBSD like approach. Cheers, Nils -- nika@acm.org nika@kassube.de 4kassube@informatik.uni-hamburg.de
participants (4)
-
Chris Withers -
Jason Cunliffe -
J�lio Dinis Silva -
Nils Kassube