Hi Uli,
Thanks for the response. I checked out the CSRF protection module but am still interested in the potential of using the HMAC passphrase as a mechanism to protect against CSRF also. I've located ClientDataEncoder and am interested in overriding this in order to salt the HMAC with JSESSIONID. I'm trying to imagine that even quite a small change to this service could also elegantly protect against CSRF on forms? Please do disregard if this sounds too outlandish or ugly to consider. Thanks! Peter ----- Original Message ----- From: "Ulrich Stärk" <u...@spielviel.de> To: "Tapestry users" <users@tapestry.apache.org> Sent: Wednesday, November 6, 2013 10:58:10 AM Subject: Re: HMAC Passphrase Could Be Much More Useful - Correct Me If I'm Wrong The HMAC is used solely to ensure that form state stored on the client side (t:formdata) hasn't been tempered with. As such its current implementation is sufficient. It is no protection against DOS (no cryptographic mechanism is) and no protection against CSRF. For CSRF protection there is a module by one of our former GSoC students, Markus Jung, at [1]. Cheers, Uli [1] http://code.google.com/p/gsoc2011-csrf-protection/ On 2013-11-06 09:44, Peter Hvass wrote: > Hello all, > > > The HMAC passphrase as is, is identical no matter the form, the time, the > session. > It seems to only be generated based on the passphrase defined in your > AppModule. > > > I don't see how this protects against DoS attacks except the most blind > assault. Nor > does it protect against CSRF (it could easily). > > > Example scenario; > 1. Malicious user visits the page with our log in form. > 2. Malicious user copies the hidden input data > 3. Malicious user can now submit that form in a verified fashion (or any > other form for that matter) > > > If your site allows user registrations lets say, an attacker could create an > account, copy a bunch > of forms (including hidden field) and send out malicious links containing > that form. This might > enable them to modify a variety of data, perhaps even hijack accounts, if the > developer isn't stringent > in adding his own security mechanisms to each and every form. > > > So since we have the basis for HMAC verification in place; why not salt it > with a session id or a timestamp? > > > This could potentially ward off a bunch of different attacks; namely CSRF. > > > And is anyone aware of which service or code handles the generation of the > hidden input value on forms? Is > this something I could override or decorate for the time being so as to have > peace of mind against CSRF attacks? :) > > > Thanks! > Peter > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
