Zope 4 publisher/traversal, sprint topic
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... Cheers, Leo
Do we really have to call it Zope 4? :-) On Thu, Oct 27, 2011 at 15:34, Leonardo Rochael Almeida <leonardo@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...
Cheers,
Leo _______________________________________________ Zope-Dev maillist - Zope-Dev@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 )
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/27/2011 10:07 AM, Lennart Regebro wrote:
Do we really have to call it Zope 4? :-)
That was the general consensus back in June: it is a BBB-incompatible release, not truly incremental to 2.12 / 2.13. Calling it "3.0" obviously unworkable. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6psv4ACgkQ+gerLs4ltQ4NXgCfYAR5qskOGdYJ0OvGSe3tRD5p XZAAoMuRSgH1EX0Pu/z9l89nBZEtPnqS =skzw -----END PGP SIGNATURE-----
On 27 October 2011 14:34, Leonardo Rochael Almeida <leonardo@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 :-)
We'll also be sprinting on Zope 4 before the Plone conference this coming Monday, Tuesday, Wednesday. There are a couple of places left, so if anyone else can make it do let me know. http://coactivate.org/projects/san-francisco-zope-sprint Laurence
Hi! Leonardo Rochael Almeida wrote:
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.
Is that the fault of the publisher? AFAICT the biggest security problem of Zope2 is this line in OFS.SimpleItem.Item: # Allow (reluctantly) access to unprotected attributes __allow_access_to_unprotected_subobjects__=1 I'm not familiar with the details of the first hotfix, but the second one wouldn't have been necessary without that line. I propose to remove that line in Zope 4 and to add explicit security declarations where ever needed. The first part is easy, the second part a lot of work for many people. Cheers, Yuppie
On 28/10/2011 08:46, yuppie wrote:
Is that the fault of the publisher? AFAICT the biggest security problem of Zope2 is this line in OFS.SimpleItem.Item:
# Allow (reluctantly) access to unprotected attributes __allow_access_to_unprotected_subobjects__=1
I'm not familiar with the details of the first hotfix, but the second one wouldn't have been necessary without that line.
Yep, that's what should have been done in the first place. cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
participants (7)
-
Chris Withers -
Jens Vagelpohl -
Laurence Rowe -
Lennart Regebro -
Leonardo Rochael Almeida -
Tres Seaver -
yuppie