[Zope-dev] CSRF protection for z3c.form

[Roger]

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?
 
Regards
Roger Ineichen

> Laurence
>