You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Peter Hvass <P....@albourne.com> on 2013/11/06 09:44:40 UTC
HMAC Passphrase Could Be Much More Useful - Correct Me If I'm Wrong
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
Re: HMAC Passphrase Could Be Much More Useful - Correct Me If I'm
Wrong
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Wed, 06 Nov 2013 07:32:23 -0200, Ulrich Stärk <ul...@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" <ul...@spielviel.de>
>> To: "Tapestry users" <us...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: HMAC Passphrase Could Be Much More Useful - Correct Me If I'm
Wrong
Posted by Ulrich Stärk <ul...@spielviel.de>.
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" <ul...@spielviel.de>
> To: "Tapestry users" <us...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: HMAC Passphrase Could Be Much More Useful - Correct Me If I'm Wrong
Posted by Peter Hvass <P....@albourne.com>.
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" <ul...@spielviel.de>
To: "Tapestry users" <us...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: HMAC Passphrase Could Be Much More Useful - Correct Me If I'm
Wrong
Posted by Ulrich Stärk <ul...@spielviel.de>.
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org