Re: [Zope-dev] CSRF protection for z3c.form
Hi Laurence Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 4 April 2011 19:16, Roger d...@projekt01.ch wrote: Hi Shane -Ursprüngliche Nachricht- Von: Shane Hathaway [mailto:sh...@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: d...@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.rich...@gmail.com Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 04/04/2011 10:22 AM, Roger wrote: Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? This thread is using the word authenticate differently than most other Zope-related discussions. Here, we are authenticating the *form*, not the user. We need to be sure that submitted form data was produced by an authentic form. Otherwise, a crafty site could cause the user's browser to invoke some action in the background. I know what you mean. As long as this is not implemented in z3c.form I'm fine Because I don't belive in this kind of protection since I did some very fancy stuff with easyxdm. Roger, Could you please describe in more detail why you don't believe in this sort of protection? As far as I can see the easyxdv messaging stuff requires supporting javascript to be executed in the context of both documents, so modulo any javascript injection vulnerabilities, it has no impact on the efficacy of form authenticators. I think to protect the form is just a part of a concept. Another part must be to prevent to inject JavaScript in user generated content. If an application allows to post JS in a blog post or comment etc. it should be possible to use easydmx to read and re-use the secure form token. (not approved but should work) One of my bigger concern is also that such a token will break a lot of our tests which whould force us to use custom non security token generating form classes. I'm fine in general for implement such a concept in z3c.form but it should be optional. Why not offer additional form classes or a mixin for support such token? Regards Roger Ineichen Laurence ___ 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] CSRF protection for z3c.form
On 4/6/11 7:43 PM, Roger wrote: [..] I think to protect the form is just a part of a concept. Another part must be to prevent to inject JavaScript in user generated content. If an application allows to post JS in a blog post or comment etc. it should be possible to use easydmx to read and re-use the secure form token. (not approved but should work) For that reason both CMF as well as Plone clean user input by stripping nasty tags and such - at least per default. Raphael One of my bigger concern is also that such a token will break a lot of our tests which whould force us to use custom non security token generating form classes. I'm fine in general for implement such a concept in z3c.form but it should be optional. Why not offer additional form classes or a mixin for support such token? Regards Roger Ineichen Laurence ___ 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] CSRF protection for z3c.form
On 6 April 2011 18:43, Roger d...@projekt01.ch wrote: Hi Laurence Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 4 April 2011 19:16, Roger d...@projekt01.ch wrote: Hi Shane -Ursprüngliche Nachricht- Von: Shane Hathaway [mailto:sh...@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: d...@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.rich...@gmail.com Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 04/04/2011 10:22 AM, Roger wrote: Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? This thread is using the word authenticate differently than most other Zope-related discussions. Here, we are authenticating the *form*, not the user. We need to be sure that submitted form data was produced by an authentic form. Otherwise, a crafty site could cause the user's browser to invoke some action in the background. I know what you mean. As long as this is not implemented in z3c.form I'm fine Because I don't belive in this kind of protection since I did some very fancy stuff with easyxdm. Roger, Could you please describe in more detail why you don't believe in this sort of protection? As far as I can see the easyxdv messaging stuff requires supporting javascript to be executed in the context of both documents, so modulo any javascript injection vulnerabilities, it has no impact on the efficacy of form authenticators. I think to protect the form is just a part of a concept. Another part must be to prevent to inject JavaScript in user generated content. If an application allows to post JS in a blog post or comment etc. it should be possible to use easydmx to read and re-use the secure form token. (not approved but should work) One of my bigger concern is also that such a token will break a lot of our tests which whould force us to use custom non security token generating form classes. I'm fine in general for implement such a concept in z3c.form but it should be optional. Why not offer additional form classes or a mixin for support such token? I intend to make it pluggable, either using an existing plug point or creating a new one. I think it's important that this can be easily retrofitted to all z3c.form based forms on a site, so I don't want to have to rely on all forms (which may come from other add-ons) needing to inherit from a particular base class. Laurence ___ 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] CSRF protection for z3c.form
Hi Laurence Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 6 April 2011 18:43, Roger d...@projekt01.ch wrote: Hi Laurence Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 4 April 2011 19:16, Roger d...@projekt01.ch wrote: Hi Shane -Ursprüngliche Nachricht- Von: Shane Hathaway [mailto:sh...@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: d...@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.rich...@gmail.com Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 04/04/2011 10:22 AM, Roger wrote: Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? This thread is using the word authenticate differently than most other Zope-related discussions. Here, we are authenticating the *form*, not the user. We need to be sure that submitted form data was produced by an authentic form. Otherwise, a crafty site could cause the user's browser to invoke some action in the background. I know what you mean. As long as this is not implemented in z3c.form I'm fine Because I don't belive in this kind of protection since I did some very fancy stuff with easyxdm. Roger, Could you please describe in more detail why you don't believe in this sort of protection? As far as I can see the easyxdv messaging stuff requires supporting javascript to be executed in the context of both documents, so modulo any javascript injection vulnerabilities, it has no impact on the efficacy of form authenticators. I think to protect the form is just a part of a concept. Another part must be to prevent to inject JavaScript in user generated content. If an application allows to post JS in a blog post or comment etc. it should be possible to use easydmx to read and re-use the secure form token. (not approved but should work) One of my bigger concern is also that such a token will break a lot of our tests which whould force us to use custom non security token generating form classes. I'm fine in general for implement such a concept in z3c.form but it should be optional. Why not offer additional form classes or a mixin for support such token? I intend to make it pluggable, either using an existing plug point or creating a new one. I think it's important that this can be easily retrofitted to all z3c.form based forms on a site, so I don't want to have to rely on all forms (which may come from other add-ons) needing to inherit from a particular base class. Ok, it starts making sense to me. What do you think about a class property like we us in fomr classes like ignoreContext, ignoreRequest, ignoreReadonly: ignoreProtection = True/False and set it by default to True? Or even to False and we can simply set it to True if test will fail because of changed form source? Regards Roger Ineichen Laurence ___ 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] CSRF protection for z3c.form
On 6 April 2011 22:24, Roger d...@projekt01.ch wrote: Hi Laurence Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 6 April 2011 18:43, Roger d...@projekt01.ch wrote: Hi Laurence Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 4 April 2011 19:16, Roger d...@projekt01.ch wrote: Hi Shane -Ursprüngliche Nachricht- Von: Shane Hathaway [mailto:sh...@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: d...@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.rich...@gmail.com Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 04/04/2011 10:22 AM, Roger wrote: Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? This thread is using the word authenticate differently than most other Zope-related discussions. Here, we are authenticating the *form*, not the user. We need to be sure that submitted form data was produced by an authentic form. Otherwise, a crafty site could cause the user's browser to invoke some action in the background. I know what you mean. As long as this is not implemented in z3c.form I'm fine Because I don't belive in this kind of protection since I did some very fancy stuff with easyxdm. Roger, Could you please describe in more detail why you don't believe in this sort of protection? As far as I can see the easyxdv messaging stuff requires supporting javascript to be executed in the context of both documents, so modulo any javascript injection vulnerabilities, it has no impact on the efficacy of form authenticators. I think to protect the form is just a part of a concept. Another part must be to prevent to inject JavaScript in user generated content. If an application allows to post JS in a blog post or comment etc. it should be possible to use easydmx to read and re-use the secure form token. (not approved but should work) One of my bigger concern is also that such a token will break a lot of our tests which whould force us to use custom non security token generating form classes. I'm fine in general for implement such a concept in z3c.form but it should be optional. Why not offer additional form classes or a mixin for support such token? I intend to make it pluggable, either using an existing plug point or creating a new one. I think it's important that this can be easily retrofitted to all z3c.form based forms on a site, so I don't want to have to rely on all forms (which may come from other add-ons) needing to inherit from a particular base class. Ok, it starts making sense to me. What do you think about a class property like we us in fomr classes like ignoreContext, ignoreRequest, ignoreReadonly: ignoreProtection = True/False and set it by default to True? Or even to False and we can simply set it to True if test will fail because of changed form source? My current thinking is a modification of my first proposal above:: def update(self): super(Form, self).update() self.updateActions() self.authenticateSubmission() self.actions.execute() if self.refreshActions: self.updateActions() def authenticateSubmission(self): if self.actions.executedActions: authenticators = zope.component.getAdapters( (self, self.request, self.getContent()), interfaces.ISubmissionAuthenticator) for authenticator in authenticators: authenticator.authenticate() This would allow for multiple authenticators to be registered as named adapters, for instance PostOnly, CheckAuthenticationToken, CheckCaptcha. Laurence ___ 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] CSRF protection for z3c.form
Hi Laurence, Stephan Betreff: Re: [Zope-dev] CSRF protection for z3c.form On Wednesday, April 06, 2011, Laurence Rowe wrote: def update(self): super(Form, self).update() self.updateActions() self.authenticateSubmission() self.actions.execute() if self.refreshActions: self.updateActions() def authenticateSubmission(self): if self.actions.executedActions: authenticators = zope.component.getAdapters( (self, self.request, self.getContent()), interfaces.ISubmissionAuthenticator) for authenticator in authenticators: authenticator.authenticate() This would allow for multiple authenticators to be registered as named adapters, for instance PostOnly, CheckAuthenticationToken, CheckCaptcha. btw, PostOnly and the condition check if self.actions.executedActions: is probably the same. Because if executedActions is False it must be a GET request. right? I like this in combination with Rgoer's ignoreProtection, which should be false by default, because we want to make forms secure by default. It would be great, if we would ship with one non-trivial authenticator and I would love to see an add-on package providing CheckCaptcha. :-) Now it becomes interesting to me and I like it more and more, let me take a closer look and discuss some details... concept naming, if we use an ignoreProtection marker let's rename the method authenticateSubmission to updateProtection which also reflects that the method is apart of the form/update method stack. And let's rename the ISubmissionAuthenticator part to smomething like IFormProtector or so. I do not like the word authentication in this concept. Authoriastion whould probably also make sense at least if captcha is involved which is authorization and not authentication. captcha, CheckCaptcha sounds very interesting and raises some questions to me. I guess if a captcha doesn't fit we need to abort processing actions and return ASAP the plain form again with another captcha. first question, I looks to me that the concept is heavy related to the action conditions. What about if each form action has it's own for protection check? a simple example: - cancel button is allowed without a check (this really will hurt if not possible) - form submit is not allowed without a check second question, should we be able to return something if the updateProtection failes. Probably the updateProtection method should return True/False and if False is returned hookup another method call which could return content ASAP (probably not possible in update stack). Or should we set a marker called like we do in AddForm with _finishedAdd? third question, I guess we should take a closer look to the action condition. It looks to me like we should implement the check closer to the form action condition concept. E.g. an action condition defines if an action get rendered and another new action argument could be called checker. Such a checker method could then check if an action can get executed or not. This whould defently require a marker flag because an action can also not return content. Or we should use a plain python error handling if a checker fails? sidenote, such a checker argument could also be used independent from the page token concept. btw, I still do not understand how the full concept will work. Where is the hook/method which will setup a token? What do you think? Regards Roger Ineichen Regards, Stephan -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ 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] CSRF protection for z3c.form
On 4 April 2011 19:16, Roger d...@projekt01.ch wrote: Hi Shane -Ursprüngliche Nachricht- Von: Shane Hathaway [mailto:sh...@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: d...@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.rich...@gmail.com Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 04/04/2011 10:22 AM, Roger wrote: Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? This thread is using the word authenticate differently than most other Zope-related discussions. Here, we are authenticating the *form*, not the user. We need to be sure that submitted form data was produced by an authentic form. Otherwise, a crafty site could cause the user's browser to invoke some action in the background. I know what you mean. As long as this is not implemented in z3c.form I'm fine Because I don't belive in this kind of protection since I did some very fancy stuff with easyxdm. Roger, Could you please describe in more detail why you don't believe in this sort of protection? As far as I can see the easyxdv messaging stuff requires supporting javascript to be executed in the context of both documents, so modulo any javascript injection vulnerabilities, it has no impact on the efficacy of form authenticators. Laurence ___ 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] CSRF protection for z3c.form
On 4 April 2011 16:53, Stephan Richter srich...@cosmos.phy.tufts.edu wrote: On Monday, April 04, 2011, Laurence Rowe wrote: The authenticator is described on http://pypi.python.org/pypi/plone.protect, but basically it adds an HMAC-SHA signed token into the form submission. By validating this you know that the submission came from a form that your site rendered, rather than an opportunistic 'drive-by' attack from another site. So why don't we make this a built-in feature then? The token manager (I think you call it the authenticator) needs to be smart, since it needs to deal with stale tokens and similar issues, but otherwise we could just add an authentication mechanism into z3c.form. Mmh, if the token gets stored in the session variable, then we do not even have to worry about token management, since the session container has already that logic. I have a feeling I am missing a level of complexity here... There should be no need to store anything in sessions, it really is as simple as ensuring that you include a signed token in the form submission that is separate from the user session identifier (as cookies get posted automatically on any form submission.) I'm happy to go with (3). I assume it is not common for z3c.form users to have non-button actions or customize the ButtonActionHandler? Not in my experience. In that case I will attempt to implement it in plone.z3cform first as that will allow me to just reuse the existing plone.protect stuff. My only concern really is how easy it will be to disable for individual forms - as I think it's important to have protection by default. I'm hoping that the following will work: * Register a ProtectedButtonActionHandler on z3c.form.form.Form (to be more specific than the default ButtonActionHandler registered on the IForm interface.) * Register the default ButtonActionHandler on a IUnprotectedForm interface, which individual forms can provide if they need to accept submissions from other sites. For a more general z3c.form protection scheme we can then look at making the zope2 dependencies in plone.protect optional. I would also like to change the token format of plone.protect to include the issue time, so secrets do not need to be rotated to invalidate old tokens, much as plone.session now does: http://pypi.python.org/pypi/plone.session Laurence ___ 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] CSRF protection for z3c.form
I've been looking into how we might add CSRF protection to z3c.form forms as we will be including z3c.form in Plone 4.1. Currently in Plone, we use plone.protect to add an authentication token to our forms and then check the token in the methods that get called. (plone.protect is BSD licensed, but is Zope2 specific.) I think it's important for the integrator to be able to add an authentication policy to all z3c.form forms on a site, so I'd rather not rely on having all forms subclass some AuthenticatedForm. I can see a number of possible ways to implement this 1. Add a hook into z3c.form.form.Form along the lines of:: def update(self): super(Form, self).update() self.updateActions() self.authenticateSubmission() self.actions.execute() if self.refreshActions: self.updateActions() def authenticateSubmission(self): if self.actions.executedActions: authenticator = zope.component.queryMultiAdapter( (self, self.request, self.getContent()), interfaces.ISubmissionAuthenticator) if authenticator is not None: authenticator.authenticate() This would allow integrators to register an ISubmissionAuthenticator that would be called when there are actions to execute (so not when a form is just displayed.) 2. Similar to (1) but fire an event. This would allow multiple submission authenticators to be registered (e.g. for post-only as well as check-authenticator), but this makes it more difficult to restrict authenticators to only certain forms / requests / contexts. 3. Register a more specific version of z3c.form.button.ButtonActionsHandler which performs the check before executing the handler. This has the advantage of not requiring any changes to z3c.form, but the disadvantages that: only button actions are protected, and would be executed per action handler execution instead of once per submission. I'd be interested to know how other z3c.form users approach CSRF protection and what approach they would recommend. Laurence ___ 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] CSRF protection for z3c.form
On Monday, April 04, 2011, Laurence Rowe wrote: I'd be interested to know how other z3c.form users approach CSRF protection and what approach they would recommend. Hi Lawrence, I am okay with (1), but find (3) ore attractive. Since I am not familiar with the token solution to avoid CSRF attacks, can you briefly describe the sequence that is used to avoid those requests? Maybe we can some up with a tightly integrated solution. I have no problem with modifying z3c.form to support such a feature. Regards, Stephan -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ 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] CSRF protection for z3c.form
On 4 April 2011 14:57, Stephan Richter srich...@cosmos.phy.tufts.edu wrote: On Monday, April 04, 2011, Laurence Rowe wrote: I'd be interested to know how other z3c.form users approach CSRF protection and what approach they would recommend. Hi Lawrence, I am okay with (1), but find (3) ore attractive. Since I am not familiar with the token solution to avoid CSRF attacks, can you briefly describe the sequence that is used to avoid those requests? Maybe we can some up with a tightly integrated solution. I have no problem with modifying z3c.form to support such a feature. Hi Stephen, The authenticator is described on http://pypi.python.org/pypi/plone.protect, but basically it adds an HMAC-SHA signed token into the form submission. By validating this you know that the submission came from a form that your site rendered, rather than an opportunistic 'drive-by' attack from another site. I'm happy to go with (3). I assume it is not common for z3c.form users to have non-button actions or customize the ButtonActionHandler? Laurence ___ 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] CSRF protection for z3c.form
On Monday, April 04, 2011, Laurence Rowe wrote: The authenticator is described on http://pypi.python.org/pypi/plone.protect, but basically it adds an HMAC-SHA signed token into the form submission. By validating this you know that the submission came from a form that your site rendered, rather than an opportunistic 'drive-by' attack from another site. So why don't we make this a built-in feature then? The token manager (I think you call it the authenticator) needs to be smart, since it needs to deal with stale tokens and similar issues, but otherwise we could just add an authentication mechanism into z3c.form. Mmh, if the token gets stored in the session variable, then we do not even have to worry about token management, since the session container has already that logic. I have a feeling I am missing a level of complexity here... I'm happy to go with (3). I assume it is not common for z3c.form users to have non-button actions or customize the ButtonActionHandler? Not in my experience. Regards, Stephan -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ 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] CSRF protection for z3c.form
Hi Laurence, Stephan Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? Regards Roger Ineichen -Ursprüngliche Nachricht- Von: zope-dev-boun...@zope.org [mailto:zope-dev-boun...@zope.org] Im Auftrag von Laurence Rowe Gesendet: Montag, 4. April 2011 15:37 An: zope-dev Betreff: [Zope-dev] CSRF protection for z3c.form I've been looking into how we might add CSRF protection to z3c.form forms as we will be including z3c.form in Plone 4.1. Currently in Plone, we use plone.protect to add an authentication token to our forms and then check the token in the methods that get called. (plone.protect is BSD licensed, but is Zope2 specific.) I think it's important for the integrator to be able to add an authentication policy to all z3c.form forms on a site, so I'd rather not rely on having all forms subclass some AuthenticatedForm. I can see a number of possible ways to implement this 1. Add a hook into z3c.form.form.Form along the lines of:: def update(self): super(Form, self).update() self.updateActions() self.authenticateSubmission() self.actions.execute() if self.refreshActions: self.updateActions() def authenticateSubmission(self): if self.actions.executedActions: authenticator = zope.component.queryMultiAdapter( (self, self.request, self.getContent()), interfaces.ISubmissionAuthenticator) if authenticator is not None: authenticator.authenticate() This would allow integrators to register an ISubmissionAuthenticator that would be called when there are actions to execute (so not when a form is just displayed.) 2. Similar to (1) but fire an event. This would allow multiple submission authenticators to be registered (e.g. for post-only as well as check-authenticator), but this makes it more difficult to restrict authenticators to only certain forms / requests / contexts. 3. Register a more specific version of z3c.form.button.ButtonActionsHandler which performs the check before executing the handler. This has the advantage of not requiring any changes to z3c.form, but the disadvantages that: only button actions are protected, and would be executed per action handler execution instead of once per submission. I'd be interested to know how other z3c.form users approach CSRF protection and what approach they would recommend. Laurence ___ 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] CSRF protection for z3c.form
On 2011-4-4 18:22, Roger wrote: Hi Laurence, Stephan Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? CSRF has nothing to do with authentication. It has to do with securing forms on websites. Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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] CSRF protection for z3c.form
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2011 12:23 PM, Wichert Akkerman wrote: On 2011-4-4 18:22, Roger wrote: Hi Laurence, Stephan Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? CSRF has nothing to do with authentication. It has to do with securing forms on websites. Imagine that Alice Malice runs a site she tempts Bob Slob to visit while Bob is logged into your site with privileged credentials. Alice adds javascript to an apparently harmless page which spoofs submitting a form to your site on Bob's behalf, perhaps granting Alice extra permissions, or defacing your site. If your site uses CSRF-protected forms, then real forms will contain hidden field whose value is a signature (a hashed value known only to the server). The server generates the hash when it renders the form, and stores it in the authenticated user's session; when the form is submitted, the server checks that the hash is valid before processing the form. Because it has either a missing or an invalid hash, Alice's spoofed submission can be rejected. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2Z9XEACgkQ+gerLs4ltQ60XgCfdsFHMrONDJfLzk/1BNN+ovN9 1ksAn0zWEAnaod3Y3oDlvkCybds1ZMNA =2/zr -END PGP SIGNATURE- ___ 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] CSRF protection for z3c.form
On 04/04/2011 10:22 AM, Roger wrote: Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? This thread is using the word authenticate differently than most other Zope-related discussions. Here, we are authenticating the *form*, not the user. We need to be sure that submitted form data was produced by an authentic form. Otherwise, a crafty site could cause the user's browser to invoke some action in the background. BTW, the CSRF issue has existed as long as HTML forms have existed, but for some reason it has only drawn attention in the past year or two. Shane ___ 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] CSRF protection for z3c.form
Hi Shane -Ursprüngliche Nachricht- Von: Shane Hathaway [mailto:sh...@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: d...@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.rich...@gmail.com Betreff: Re: [Zope-dev] CSRF protection for z3c.form On 04/04/2011 10:22 AM, Roger wrote: Just because you can write login forms with z3c.form this package has nothing to do with authentication. That's just a form framework! Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? This thread is using the word authenticate differently than most other Zope-related discussions. Here, we are authenticating the *form*, not the user. We need to be sure that submitted form data was produced by an authentic form. Otherwise, a crafty site could cause the user's browser to invoke some action in the background. I know what you mean. As long as this is not implemented in z3c.form I'm fine Because I don't belive in this kind of protection since I did some very fancy stuff with easyxdm. Regards Roger Ineichen BTW, the CSRF issue has existed as long as HTML forms have existed, but for some reason it has only drawn attention in the past year or two. Shane ___ 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] CSRF protection for z3c.form
Hi Stephan Betreff: Re: AW: [Zope-dev] CSRF protection for z3c.form On Monday, April 04, 2011, Roger wrote: Authentication is defently not a part of our z3c.form framework and should not become one. Why do you think authentication has something to do with the z3c.form library? Did I miss something? Roger, this has nothing to with user authentication, but rather form authenticity, as in: Has the user submitted the same form s/he has received in the first place. I was confused the first time I was reading. But it doesn't matter if we check authentication or page tokens. Both are a check for did the users browser access this page before. But anyway, form authencity is nice but an illusion. All we can do is to make it harder to attack a form. Google CSRF. The Wikipedia article was pretty good. I know the different concepts since I wrote some XXS based bookmark scripts and did some experiments with easyxdm and z3c.jsonrpcproxy. In my point of view a page token is just a part of a security concept and doesn't help as THE solution. Probably we could implement a mixin class like: class ProtectorMixin(object): def update(self): # inject and validate page token super(ProtectorMixin, self).update() Here are my reasons why this should not go to the default classes: - it slows things down - it suggests secure forms but doesn't without other protection concepts - it makes the not so simple z3c form concept even more complex - it's an overhead to protect any form by default or lookup non existing adapters What do you think? Regards Roger Ineichen ___ 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 )
