On Wed, 06 Nov 2013 07:32:23 -0200, Ulrich Stärk <u...@spielviel.de> wrote:
Well I guess it could be, leveraging the Encrypted Token Pattern.
Agreed. JIRA please! ;)
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
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
