Hi shane,

Oliver Bleutgen wrote:

...

From a non-technical, PR-wise point of view let me add that this type of "vulnerability" easily gets zope mentioned on lists like bugtraq. The perception is that these thing really are vulnerabilities.

You're right, a quick search on google for "path disclosure vulnerability" yields a lot of hits for lots of applications.

It troubles me that people consider PDV to be important at all when the client-side trojan bug is still fully exploitable on all browsers including IE and Mozilla! (AFAIK) Client-side trojans, which can cause your browser to invisibly post a comment on a weblog, execute a financial transaction, or break into servers you maintain, are a major risk.

I had put something about that theme at the client-side trojan wiki, put I'll repeat myself since you mentioned it ... Methinks the creators of the http/1.1 rfc were aware of the dangers we call client-side trojan and wrote the following: " 9.1.1 Safe Methods 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. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. " Zope really should not accept GET requests to dangerous manage_* (or other) methods, that would ensure it's at least compliant with the spirit of that rfc. If the user decides to use a browser which allows javascript to auto-submit forms and stuff, it's his choice. I have a feeling that other ideas like checking referer etc. are bound to fail after one or two generations of new browsers. We should have in mind that the same people who will design these browsers already had the bright idea of implementing auto-submitting of hidden forms.

PDV just yields information you might give out anyway. But maybe we could deal with it anyway by writing an "error.log" instead of sending the traceback to the browser. What do you think?

I fear it would make working with zope harder for unexperienced users. When working with apache/perl on linux, I always had a tail -f /var/log/httpd/error.log running in a terminal, but if you're solely working on windows without using the power of cygwin or other tools, this might get tedious. What I would like to see is a error "product" which can be freely configured to show more or less details depending on its context (i.e. user/role etc.) and able to optionally write to a log file. I know this is a lot of work and has its technical problems, but it's a nice imagination. cheers, oliver