> 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
> 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
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
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
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.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -