Well I guess it could be, leveraging the Encrypted Token Pattern. Uli
On 2013-11-06 10:07, Peter Hvass wrote: > 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 > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
