[Zope-dev] Vulnerability: attacking can get file list and dir ectory

[sean.upton@uniontrib.com]

Personally, I think this really should be an integration issue instead of a
Zope issue: use a front-end proxy server (i.e. Squid) and set up ACLs to
prevent this...
Sean

-----Original Message-----
From: Oliver Bleutgen [mailto:myzope@gmx.net]
Sent: Monday, September 24, 2001 9:10 AM
To: zope-dev@zope.org
Subject: Re: [Zope-dev] Vulnerability: attacking can get file list and
directory


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

_______________________________________________
Zope-Dev maillist  -  Zope-Dev@zope.org
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 )