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
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"
On 4 April 2011 14:57, Stephan Richter <srichter@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
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"
On 4 April 2011 16:53, Stephan Richter <srichter@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
Hi Laurence
Betreff: Re: [Zope-dev] CSRF protection for z3c.form
On 4 April 2011 16:53, Stephan Richter <srichter@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
Does this (optimized) session concept work with (robin arround) load balanced servers? Probably I don't understand some parts of the form token. Does the form generate random tokens or allways the same? 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 )
On 6 April 2011 18:52, Roger <dev@projekt01.ch> wrote:
Hi Laurence
Betreff: Re: [Zope-dev] CSRF protection for z3c.form
On 4 April 2011 16:53, Stephan Richter <srichter@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
Does this (optimized) session concept work with (robin arround) load balanced servers?
Yes, it has nothing to do with Zope sessions. You can share it between multiple systems by setting the same shared secret on each one. (In plone.session the secret is stored in the ZODB, so you only need to set a shared secret when you want to share login cookies between multiple plone sites or with other systems.)
Probably I don't understand some parts of the form token. Does the form generate random tokens or allways the same?
A token is generated containing the current user and the time when the form is rendered, or in the plone.session case when the user logs in. The token is securely signed using the secret, so it can be subsequently validated. The time is used to limit validity to say 12 hours (or less if you are feeling paranoid.) Laurence
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-bounces@zope.org [mailto:zope-dev-bounces@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 )
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 <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
-----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 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/ iEYEARECAAYFAk2Z9XEACgkQ+gerLs4ltQ60XgCfdsFHMrONDJfLzk/1BNN+ovN9 1ksAn0zWEAnaod3Y3oDlvkCybds1ZMNA =2/zr -----END PGP SIGNATURE-----
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
Hi Shane
-----Ursprüngliche Nachricht----- Von: Shane Hathaway [mailto:shane@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: dev@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.richter@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
On 4 April 2011 19:16, Roger <dev@projekt01.ch> wrote:
Hi Shane
-----Ursprüngliche Nachricht----- Von: Shane Hathaway [mailto:shane@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: dev@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.richter@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
Hi Laurence
Betreff: Re: [Zope-dev] CSRF protection for z3c.form
On 4 April 2011 19:16, Roger <dev@projekt01.ch> wrote:
Hi Shane
-----Ursprüngliche Nachricht----- Von: Shane Hathaway [mailto:shane@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: dev@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.richter@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
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 )
On 6 April 2011 18:43, Roger <dev@projekt01.ch> wrote:
Hi Laurence
Betreff: Re: [Zope-dev] CSRF protection for z3c.form
On 4 April 2011 19:16, Roger <dev@projekt01.ch> wrote:
Hi Shane
-----Ursprüngliche Nachricht----- Von: Shane Hathaway [mailto:shane@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: dev@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.richter@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
Hi Laurence
Betreff: Re: [Zope-dev] CSRF protection for z3c.form
On 6 April 2011 18:43, Roger <dev@projekt01.ch> wrote:
Hi Laurence
Betreff: Re: [Zope-dev] CSRF protection for z3c.form
On 4 April 2011 19:16, Roger <dev@projekt01.ch> wrote:
Hi Shane
-----Ursprüngliche Nachricht----- Von: Shane Hathaway [mailto:shane@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: dev@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.richter@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
On 6 April 2011 22:24, Roger <dev@projekt01.ch> wrote:
Hi Laurence
Betreff: Re: [Zope-dev] CSRF protection for z3c.form
On 6 April 2011 18:43, Roger <dev@projekt01.ch> wrote:
Hi Laurence
Betreff: Re: [Zope-dev] CSRF protection for z3c.form
On 4 April 2011 19:16, Roger <dev@projekt01.ch> wrote:
Hi Shane
-----Ursprüngliche Nachricht----- Von: Shane Hathaway [mailto:shane@hathawaymix.org] Gesendet: Montag, 4. April 2011 19:54 An: dev@projekt01.ch Cc: 'Laurence Rowe'; 'zope-dev'; stephan.richter@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
participants (7)
-
Laurence Rowe -
Raphael Ritz -
Roger -
Shane Hathaway -
Stephan Richter -
Tres Seaver -
Wichert Akkerman