[Zope-dev] CSRF protection for z3c.form

[Laurence Rowe]

On 6 April 2011 22:24, Roger <dev at projekt01.ch> wrote:
> Hi Laurence
>
>> Betreff: Re: [Zope-dev] CSRF protection for z3c.form
>>
>> On 6 April 2011 18:43, Roger <dev at projekt01.ch> wrote:
>> > Hi Laurence
>> >
>> >> Betreff: Re: [Zope-dev] CSRF protection for z3c.form
>> >>
>> >> On 4 April 2011 19:16, Roger <dev at projekt01.ch> wrote:
>> >> > Hi Shane
>> >> >
>> >> >> -----Ursprüngliche Nachricht-----
>> >> >> Von: Shane Hathaway [mailto:shane at hathawaymix.org]
>> >> >> Gesendet: Montag, 4. April 2011 19:54
>> >> >> An: dev at projekt01.ch
>> >> >> Cc: 'Laurence Rowe'; 'zope-dev'; stephan.richter at 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