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/