[Zope] Security Problem

[jamesd@mena.org.au]

Having to create a new Manager and Reviewer role for each of the portals I
host and setting it up to work correctly (considering checking for the role
'Manager' is hard coded in many places) would be an enormous task, so this
is not feasable.

Considering the exploit does not affect folders (going to
plone2/portals/manage_main does not work, while plone2/plone1/manage_main
does, where 'portals' is a folder) is there a way to force the permissions
to be inherited from 'container' and not 'context'?


> Yep.  This is a huge vulnerability in certain configurations.
>
> But the *real* problem is not that plone1 methods can be applied to
> plone2 objects.  That is a feature, not a bug. :-)
>
> Rather, the problem is that you have implicitly *permitted* this to
> take place by using common roles across sites.  I suspect that you're
> hardly alone in setting up your site this way.  In fact, I was auditing
> one of my own sites and stumbled across a variant of this technique
> that
> allowed arbitrary access to virtually any object on the server.  Yikes!
>
> I'm working on a howto for this concern... but in the interim, I'd
> strongly recommend taking three steps to secure *any* multi-user,
> multi-host Zope app:
>
> 1. Reserve the Manager role for server administration only.  Just as
> importantly, don't *ever* assign a Manager proxy role unless you are
> certain you've worked out all the implications of that method being
> applied to arbitrary objects.
>
> 2. Use different roles for different groups of users.  Create
> site-specific, function-specific roles like site1_admin, site2_admin,
> site1_user, etc.  Use server-wide roles  sparingly and define them
> narrowly (send_mail, add_user, etc).
>
> 3. Disable/restrict "view folder contents" permissions for all folders
> that are parents of your site root folders.  Leaving that permission
> turned on for Anonymous (the default) allows virtually anyone to obtain
> details about your server setup that are quite handy for setting up
> cross-site scripting exploits.  It's shockingly easy to do this and
> there are few (if any) reasons why you'd want that feature enabled for
> parents of your site roots anyway.
>
> HTH,
>
> Dylan