[Zope-dev] Zope 4 publisher/traversal, sprint topic

Lennart Regebro regebro at gmail.com
Thu Oct 27 14:07:24 UTC 2011


Do we really have to call it Zope 4? :-)

On Thu, Oct 27, 2011 at 15:34, Leonardo Rochael Almeida
<leonardo at nexedi.com> wrote:
> Hi,
>
> Sorry for the cross-post, but I'd like to talk about a possible sprint
> topic for the next DZUG sprint[1], and invite myself to it :-)
>
> After the last two rather serious security issues that were recently
> patched in the Zope2 code base, it is increasingly clear to me that,
> differently than what Hanno reported some time ago, it's not so much
> the ZMI that represents a huge security liability in the Zope
> codebase, but it's actually the way the current publisher happily
> traverses any attribute and publishes any method with docstring by
> default.
>
> The ZMI, of course, has its problems (ugly in appearance and even
> uglier in code), and I agree with Hanno on most everything he has to
> say about it, but I'd like to propose we start, for Zope 4, by
> tackling the potential security liability that is the Zope publisher
> itself, and the fact that it makes it easy to open up large security
> holes if you're not paying attention.
>
> I'd like to propose that publishing traversal in Zope 4 would, by
> default only traverse based on __getitem__ (not attribute lookup). For
> a minimum of backward compatibility, it could perhaps do a single
> traversal on getattr, and only after it has exhausted __getitem__
> traversal.
>
> After this, if the traversal found something, it would only be
> published if there is an explicit indication of intention that the
> object in question is supposed to be published. Otherwise, raise a
> NotFound, as if the traversal had failed.
>
> One example of an explicit demonstration of intent is, for example, if
> it provides an IPublishable interface (I just made that up, other
> names can be considered).
>
> Taking a suggestion from Shane, we could have convenient decorators
> for people who wants to explicitly publish class methods. They could
> dynamically create ZTK views with the same name as the function that
> they wrap and allow (or perhaps enable by default) some form of CSRF
> protection.
>
> To ease code migration, we could consider that the InitializeClass
> call provides the same effect as the above decorator. This would allow
> large amounts of previously existing code to work without recoding,
> while at the same time avoiding the security trap of forgetting to
> call InitializeClass and thus exposing unintented methods. It could
> even remove the need for the "single getattr traversal" compatibility
> above.
>
> On top of that, if InitializeClass register these views to a specific
> ZTK "skin", it would make it possible to disable them by default,
> unless that specific skin is in effect, which would alleviate what
> Hanno described as "running phpMyAdmin accessible to the world with
> the same credentials and on the same domain as the rest of your
> application".
>
> Anyway, I think the above is on-topic for the next DZUG sprint and I'd
> like to work on it there.
>
> So, even if the sprint is supposed to be in German, and I don't speak
> a word of it, can I attend?
>
> [1] http://www.zope.de/community/veranstaltungen/3.-dzug-sprint-2011-zmi
> , translation at:
> http://translate.google.com/translate?hl=en&sl=auto&tl=en&u=http%3A%2F%2Fwww.zope.de%2Fcommunity%2Fveranstaltungen%2F3.-dzug-sprint-2011-zmi
>
> Cheers,
>
> Leo
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at zope.org
> https://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists -
>  https://mail.zope.org/mailman/listinfo/zope-announce
>  https://mail.zope.org/mailman/listinfo/zope )
>


More information about the Zope-Dev mailing list