[Zope] Securing Zope and Special URLs

Jamie Heilman jamie at audible.transient.net
Wed Sep 10 16:08:56 EDT 2003


Roy Rapoport wrote:
> As part of a re-engineering of our Zope infrastructure, I'm tasked with
> finding any documentation out there on how to secure Zope sites in a
> best-practices sort of way.  Anyone got any pointers?

Yes, but its a waste of time.
 
> Also, we're fronting Zope with Apache using mod_proxy to relay requests
> through.  We'd like to block Zope management-type URLs from coming through
> the Apache server and hitting the Zope server (we'll do our management
> directly to the Zope instance).  For this, I need to figure out what special
> patterns signify a Zope management URL.

Next to impossible.

> Some patterns I know about already include:
> /.*/[^/]*manage[^/]*$ (Any URL whose last component (excluding args)
> includes 'manage')
> /acl_users/
> ^/Control_Panel.*
> ^manage_addProduct/
> ^manage/
> 
> Any others?

There are tons of published methods which are only available to
manager-types.  The manage_* pattern seems to have been entirely
abandoned by some module authors.  It would be extremely time
consuming to track down every last one, but wait... it gets better, er
worse.  Even if you track down every single suspect pattern, you
haven't actually stopped anyone from accessing them.

Zope bends over backwards to expose as many of its objects as it can,
to as many publishing techniques as feasible.  Even if you insert URI
filters to weed out the obvious targets you've only closed off 1
avenue of many.  You'll still have to contend with XML-RPC, the
type-coersion hooks in ZPublisher which can alter the traversal stack,
products that allow traversal stack manipulation, WebDAV, etc. and
thats just over HTTP.  You can't filter POST requests in Apache
without 3rd party extentions, and even if you could, it would just
make your life hopelessly complicated.  (Well ok, thats not entirely
true, you could limit requests to GET/HEAD only, then come up with a
heavily restrictive set of GET filters... but thats obviously only
going to work for a limited number of situations.)

Best practices for system security on a Zope host are the same as they
are on any host that runs an untrusted service of daunting complexity.
Jail the hell out of it, make sure you have sensible resource limits
in place, and don't bundle it on the same host with anything else you
need to place a high level of trust in.

As for application-level security within the Zope environment... don't
assume you're going to get any.  If I was going to give somebody
advice on how to use Zope, who's just starting out and is concerned
about application security, but who didn't want to get knee deep in
the code itself, I'd say
1) Change the ACLs on the root Application (Folder) object to be as
   restrictive as you can get away with.
2) Remove every Product Zope ships with that you don't plan on using.
   (when subsystems break, and they will, try to remove them too)
3) Never use DTML.

-- 
Jamie Heilman                     http://audible.transient.net/~jamie/



More information about the Zope mailing list