Re: [Framework-Team] PLIP 224: CSRF protection framework
On Jan 31, 2008, at 10:15 PM, Andreas Zeidler wrote: in contrary to my statement regarding the other reviews, i.e. that two review ought to do (considering how late we are already), in this case it should be: the more, the merrier. hence, i'd offer to do a review as well and i'd suggest that martijn has a look at this, too. fyi, i've finished the review on the plane home and added my notes to https://dev.plone.org/plone/ticket/7783 cheers, andi -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.5 released! -- http://plone.org/products/plone PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 224: CSRF protection framework
On Jan 31, 2008, at 9:58 PM, Andreas Zeidler wrote: On Jan 31, 2008, at 7:15 PM, Wichert Akkerman wrote: At this moment I do not have a review bundle ready; I'm hoping that someone will beat me to it since I have very little time to work on it. hmm, i guess i could try to set up a buildout, [...] i've created review bundle[*], but you're gonna have to fill in the review notes yourself... ;) andi [*] see http://dev.plone.org/plone/ticket/7783#comment:3 -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.5 released! -- http://plone.org/products/plone PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 224: CSRF protection framework
Wichert Akkerman wrote: Previously Raphael Ritz wrote: There is one question I have already now: Who feels responsible for updating the forms that ship with Plone/AT to make use of this? (or am I missing something?) And don't get me wrong: I have no problem shipping it even without using it right away just to make it readily available. A few quick comments: It is only important for the forms that are security sensitive. Of course That comes down to personalize_form, Yup the control panel forms which are a few and the sharing form. and don't forget that there are some that we ship without offering them in the default UI like the ownership_form Perhaps a few others, but I think that list is quite complete already. Alex suggested the other day that AT itself could use this as well; considering how simple it is to use that should indeed be doable with a few small changes in base_edit.pt and processForm. I agree that with these two we should be quite safe already. Where I am lacking some overview and understanding at the moment are the things KSS uses. Personally I'm not convinced we need to do this everywhere, but since the performance effect should be very small it won't hurt either. Either way I can think of no reason at the moment to not include this as soon as possible. Raphael Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 224: CSRF protection framework
how about getting the important ones done for 3.1 and perhaps making generic support a PLIP for 3.2? andi ps: thanks wichert for coming up with those two packages so quickly, btw! On Jan 31, 2008, at 9:55 PM, Wichert Akkerman wrote: A few quick comments: It is only important for the forms that are security sensitive. That comes down to personalize_form, the control panel forms and the sharing form. Perhaps a few others, but I think that list is quite complete already. Alex suggested the other day that AT itself could use this as well; considering how simple it is to use that should indeed be doable with a few small changes in base_edit.pt and processForm. Personally I'm not convinced we need to do this everywhere, but since the performance effect should be very small it won't hurt either. Wichert. -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.5 released! -- http://plone.org/products/plone PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 224: CSRF protection framework
On Jan 31, 2008, at 9:20 PM, Raphael Ritz wrote: At this moment I do not have a review bundle ready; I'm hoping that someone will beat me to it since I have very little time to work on it. OK, so I'll take on the role of beating you to this and I'll try to sneak in a review during the sprint in Davis - maybe even by someone more competent on this than me ;-) that'd be great — in contrary to my statement regarding the other reviews, i.e. that two review ought to do (considering how late we are already), in this case it should be: the more, the merrier. hence, i'd offer to do a review as well and i'd suggest that martijn has a look at this, too. that's if time allows, of course. we've been following the discussion wichert mentioned anyway, so i guess it also makes sense for us to follow up on this. Refering to your statement: "A user interface to manage keyrings as well as a system to automatically rotate keyrings is highly desirable." is of course understandable but I wouldn't even insist on that. we should try to get this in nevertheless. and if it doesn't work out in time for 3.1, it should be added asap afterwards, perhaps even in a otherwise bugfix-only release. the reason behind this is that without it too many people just won't bother to set things up in a secure way. andi -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.5 released! -- http://plone.org/products/plone PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 224: CSRF protection framework
On Jan 31, 2008, at 7:15 PM, Wichert Akkerman wrote: See http://plone.org/products/plone/roadmap/224 for details. I absolutely hate to do this since it violates our process and we already have a large number of PLIPs waiting for review, but I am proposing this PLIP for Plone 3.1. definitely a +1 on this from me. not doing it right away simply doesn't make sense, imho... The implementation is based on a long debate we had in the security team recently as a result of a discussion with a security researcher contacting us about possible Plone security issues. ...and we can't keep them holding back their paper for too long, anyway. At this moment I do not have a review bundle ready; I'm hoping that someone will beat me to it since I have very little time to work on it. hmm, i guess i could try to set up a buildout, but what's the status about determining the relevant forms and adding the protection to them? andi -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.0.5 released! -- http://plone.org/products/plone PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 224: CSRF protection framework
Previously Raphael Ritz wrote: > There is one question I have already now: Who feels responsible > for updating the forms that ship with Plone/AT to make use of > this? (or am I missing something?) And don't get me wrong: > I have no problem shipping it even without using it right away > just to make it readily available. A few quick comments: It is only important for the forms that are security sensitive. That comes down to personalize_form, the control panel forms and the sharing form. Perhaps a few others, but I think that list is quite complete already. Alex suggested the other day that AT itself could use this as well; considering how simple it is to use that should indeed be doable with a few small changes in base_edit.pt and processForm. Personally I'm not convinced we need to do this everywhere, but since the performance effect should be very small it won't hurt either. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 224: CSRF protection framework
Wichert Akkerman wrote: See http://plone.org/products/plone/roadmap/224 for details. I absolutely hate to do this since it violates our process and we already have a large number of PLIPs waiting for review, but I am proposing this PLIP for Plone 3.1. Anarchist as I am I have no problem personally with exceptions ;-) The reason I am willing to do this is that it improves the security of Plone: it adds protection against the unfortunately quite common CSRF type of attacks. The implementation is based on a long debate we had in the security team recently as a result of a discussion with a security researcher contacting us about possible Plone security issues. I've been sort of following your recent checkins on the issue and while I'm no technical expert on the matter I do agree that this warrants an exception. Sort of like "Security first". At this moment I do not have a review bundle ready; I'm hoping that someone will beat me to it since I have very little time to work on it. OK, so I'll take on the role of beating you to this and I'll try to sneak in a review during the sprint in Davis - maybe even by someone more competent on this than me ;-) I'd only like to better understand your judgment (quote from the PLIP): "There are no known risks. There is very little migration needed: two new packages need to be added to the Plone instance and the persistent utility from plone.keyring needs to be instantiated. All existing forms will continue to work. In order to use the newly available protection they can be modified by a single line of TAL in the template and a single line of python in the backend code." by trying it out myself and looking more closely at it before I say more. Refering to your statement: "A user interface to manage keyrings as well as a system to automatically rotate keyrings is highly desirable." is of course understandable but I wouldn't even insist on that. There is one question I have already now: Who feels responsible for updating the forms that ship with Plone/AT to make use of this? (or am I missing something?) And don't get me wrong: I have no problem shipping it even without using it right away just to make it readily available. What do others think? Raphael Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
