Re: [Zope-dev] Zope 4 publisher/traversal, sprint topic
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 ___ 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 )
Re: [Zope-dev] Zope 4 publisher/traversal, sprint topic
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 ___ 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 )
[Zope-dev] 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=ensl=autotl=enu=http%3A%2F%2Fwww.zope.de%2Fcommunity%2Fveranstaltungen%2F3.-dzug-sprint-2011-zmi 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 )
Re: [Zope-dev] Zope 4 publisher/traversal, sprint topic
Do we really have to call it Zope 4? :-) On Thu, Oct 27, 2011 at 15:34, Leonardo Rochael Almeida leona...@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=ensl=autotl=enu=http%3A%2F%2Fwww.zope.de%2Fcommunity%2Fveranstaltungen%2F3.-dzug-sprint-2011-zmi 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 ) ___ 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 )
Re: [Zope-dev] Zope 4 publisher/traversal, sprint topic
On Oct 27, 2011, at 16:07 , Lennart Regebro wrote: Do we really have to call it Zope 4? :-) Yes. jens ___ 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 )
