You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Martijn Brinkers (List)" <ma...@gmail.com> on 2008/08/05 21:41:34 UTC
Re: T5: How to protect against 'Cross-site request forgery'?
> Also, the internal LinkFactory service has listeners that know when an
> action link is created; it might be possible to automatically add a
> query parameter to every link with authentication, and then provided
> filters in the ComponentEventRequestHandler pipeline to enforce the
> check.
I finally had time to implement the 'Cross-site request forgery' filter
in the way suggested by Howard and it was really simple and
straightforward (which shows me again why I think Tapestry is extremely
well built). All action links now contain a sid (random generated for
each user) and the sid is checked using a ComponentEventRequestFilter.
The only possible problem (which was not a problem for me though) could
be that the action links now contain an extra parameter
(example: ?sid=enn50tk96) which wasn't there before the filter was
added. This can interfere with existing code. I was wondering whether it
would be possible to remove the sid attribute after checking the sid so
the rest of the application has no knowlegde of the sid?
Martijn
On Mon, 2008-07-28 at 12:27 -0700, Howard Lewis Ship wrote:
> I wonder if this could be created as a Mixin?
>
> Also, the internal LinkFactory service has listeners that know when an
> action link is created; it might be possible to automatically add a
> query parameter to every link with authentication, and then provided
> filters in the ComponentEventRequestHandler pipeline to enforce the
> check.
>
> On Mon, Jul 28, 2008 at 12:24 PM, Martijn Brinkers (List)
> <ma...@gmail.com> wrote:
> > Hi Christian,
> >
> > Do you have some example code of you Form extension?
> >
> > Thanks,
> >
> > Martijn
> >
> > On Mon, 2008-07-28 at 15:18 -0400, Christian Edward Gruber wrote:
> >> A good way would be to alter the Form object to contain (via a hidden
> >> variable) a field that's generated per the whitepaper linked from that
> >> wikipedia article. The form would then consume the post, and if that
> >> field is not in the expected state, generate an error state, which
> >> could then be redirected to a security page or some such. We solved
> >> it this way, though without changing the T5 form object - we used a
> >> custom form object.
> >>
> >> A friend of mine wrote the linked whitepaper, so if someone's trying
> >> to put the fix into the Tapestry framework infrastructure, then let me
> >> know and I'll connect you by e-mail. It's a good read anyway, as it's
> >> a bit of a subtle problem.
> >>
> >> Christian.
> >>
> >> On 28-Jul-08, at 14:50 , Martijn Brinkers (List) wrote:
> >>
> >> > Cross-site request forgeries (CSRF) is a web application vulnerability
> >> > that is often neglected by web developers. If your application is
> >> > vulnerable to CSRF and an attacker can entice you to request some URL
> >> > (this can be done for example with an image with the src set to some
> >> > Tapestry action) the attacker can execute random Tapestry actions and
> >> > post forms (like adding a adminitrator etc.) without the users
> >> > consent.
> >> > For more info on CSRF see for example:
> >> > http://en.wikipedia.org/wiki/Cross-site_request_forgery.
> >> > One way to protect against CSRF is to add a non-guessable code
> >> > (saved in
> >> > the user session) to the URLs that need to be protected against CSRF
> >> > or
> >> > add a hidden field to a Form with this unique code. When Tapestry
> >> > recieved a request (for a page or action) and that page/action need
> >> > protection a check is done to see if the code from the URL matches the
> >> > code stored in the user session. If not you know that the request did
> >> > not generated by tapestry.
> >> >
> >> > My question is what is the best way to implement this? Should I add
> >> > the
> >> > code as a context parameter and for forms as a hidden field? And use a
> >> > dispatcher to check whether the page should have been protected?
> >> >
> >> > Thanks,
> >> >
> >> > Martijn Brinkers
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > 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
> >>
> >
> >
> > ---------------------------------------------------------------------
> > 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: T5: How to protect against 'Cross-site request forgery'?
Posted by 9902468 <vi...@cerion.fi>.
I read the document and it is good.
I wasn't referring to non-cryptographic tokens, just to the fact that the
whole token doesn't have to be generated every request, just the request
unique part. Imagine what ever token that you would use: I would just
concatenate the unique request part to it. That doesn't make it any easier
to guess.
In my model the malicious user would have to guess the token AND the request
unique part.
And no starting point is needed, if all my pages happen to inherit from a
page that triggers the creation of session and the token, if needed. (Or the
framework could do it automatically.)
Direct linking in our software is non-issue in secured parts.
Is there such thing as overkill when implementing security? I personally
would like see the possibility to toggle it on (Application wide.) by
default and explicitly toggle it off (Link/Form/Page) where I want direct
linking etc work. The framework default should be off (Application wide.),
unless explicitly set on where needed (Link/Form/Page).
-99
Christian Edward Gruber-2 wrote:
>
> Incidentally, on Java get and post are the same, unless someone
> implements the servlet and overrides post and get. At present, get
> and post both direct to the same method. That's bad. But I'm not
> saying "trust post", I'm saying that get is worse than post, except
> that the above turns them both into the same thing.
>
> Anyway, the article I was referring to (which describes some of the
> issues involved with fixing it) is:
> http://www.isecpartners.com/documents/XSRF_Paper.pdf
>
> The issue with xsrf has to do with application design and actions.
> Navigation itself is not an issue, but actions that do something.
>
> As to the issue of using non-cryptographic tokens, it's insane.
> Timing/guessing is the root of most exploits and the way to defeat
> XSRF is to ensure that the "action formulator" and the "action
> receiver" both agree on the number, and that an intervening party that
> replays the action can't guess the new number. If you're incrementing
> or decrementing on the first number, an attacker only has to try an
> increment likely to be too high, then repeat it until the increment
> count reaches his selected number.
>
> Anyway, I'm not saying don't do it on every single post, it's just
> that it's overkill, overcomplicates urls (because you have to use it
> on URLs sometimes), and you need to be able to turn it off where it's
> not needed anyway, because new sessions won't have a number, so you
> need a starting point where it's turned on. Now maybe that point is a
> redirect to an entry point that's known, but that means you can't, by
> definition, have direct linking to anything in the application.
> Anyway, please read this paper - the solutions are good, and the
> framework can enable the solution, but can't solve it for you.
>
> Christian.
>
> On 6-Aug-08, at 09:29 , 9902468 wrote:
>
>>
>> I don't think that people should trust post anymore than get.
>> Period. They
>> should both be regarded as dangerous.
>>
>> The second issue of placing too much load on server is valid, but
>> can be
>> lowered as the unique request part in the token can be achieved
>> using a
>> running number on the generated token, not to generate the whole
>> token for
>> every request. Granted that user can guess the number easily, but
>> there
>> really is no harm if user alters the number or the token, then it just
>> doesn't match. (Same as your model but the running number added.)
>> This does
>> add some perfomance penalty, but I believe that it is acceptable.
>>
>> The point that really critical things should always be confirmed via
>> non-computer way is good, but sometimes unacceptable. Then one must
>> settle
>> to what can be done.
>>
>> You said "Blanket solutions don't make you secure if they're knee-
>> jerk.".
>> And I agree. But "...applying broad strokes isn't a good model of
>> security,
>> in my view." is not right in this context in my opinion. Is there
>> harm done
>> if token is used in every request (performance questions ignored)?
>>
>> This solution is not the save-everything by all means, just one tool
>> in our
>> box.
>>
>> - 99
>>
>> Ps. I agree that the capability to have a secure request key be
>> built into
>> ActionLink, Page, and Form is enough. (Although there could be
>> configuration
>> symbol which configures the default, thus enabling the default to be
>> on or
>> off and then developer could override that if needed.)
>>
>>
>> Christian Edward Gruber-2 wrote:
>>>
>>> Ok, people should read the whitepaper. Part of it describes how http
>>> gets and using query parameters are somewhat easier to do request
>>> forging on than posts. I have to think through the filter approach,
>>> but the big deal is on forms. However, several app design principles
>>> also apply - in particular, ensuring that there are no changes that
>>> one can make, if one were forged, that don't include notification
>>> that
>>> the change was made to the original e-mail address of the user.
>>>
>>> The classic example is on a bank site. If i can forge a request to
>>> change the notification e-mail, then can set my own e-mail as the new
>>> notification source. THEN I can do all sorts of things, including
>>> ask
>>> for a password reset and get them to my own address, and take over
>>> the
>>> account. If, however, such underlying account changes require a
>>> phone
>>> call, or are protected from forgery, then you dramatically limit the
>>> danger of the forgery.
>>>
>>> The reason I'd not enable this on every single request (especially
>>> navigation alone) is that generating a cryptographically valid
>>> request
>>> key and storing it puts a pretty high burden on a server with any
>>> serious load, and having this happen on any and every click can be
>>> quite expensive. The only caveat I'd make to that is the fact that
>>> T5 uses some parameterization via the URL, and if those parameters
>>> are
>>> worth forging, then having the solution implemented on clicks as well
>>> would be critical.
>>>
>>> Blanket solutions don't make you secure if they're knee-jerk. You
>>> still have to do threat modelling, and incorporate it into the app
>>> design. I'd much rather see the capability to have a secure request
>>> key be built into ActionLink, Page, and Form, to allow one to enable
>>> it with a flag, according to what needs protecting. T5, having the
>>> component consume its own data is in a much better place to implement
>>> this cleanly in a few key components than Struts or other things.
>>> But
>>> getting nervous about XSRF (or CSRF or whatever the current acronym
>>> is
>>> today) and applying broad strokes isn't a good model of security, in
>>> my view.
>>>
>>> Unfortunately, I can't provide source code for our example, as I
>>> don't
>>> have it any more, and it was client code. I'm in the thick of other
>>> source and other issues, so I don't really have time to implement it.
>>> I do have a client that may need it, so if I get there before a good
>>> general solution is adopted in T5, I'll try to write it in a way that
>>> I can share the source with the community.
>>>
>>> Christian.
>>>
>>> On 6-Aug-08, at 03:13 , 9902468 wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> CSRF solution could be the base for the solution to my problem,
>>>> described
>>>> here:
>>>>
>>>> http://www.nabble.com/T5-double-click---multiple-windows-on-same-session-prevention-to18807447.html
>>>>
>>>> Could you post the code? I think that I need only to customize it so
>>>> that it
>>>> changes the sid to every response and accepts only request with the
>>>> latest
>>>> one.
>>>>
>>>> I'm also interested of the mixin(s) code. (Or the custom action
>>>> link / form
>>>> implementation if that approach was chosen.)
>>>>
>>>> - 99
>>>>
>>>>
>>>> Martijn Brinkers (List)-2 wrote:
>>>>>
>>>>>> Also, the internal LinkFactory service has listeners that know
>>>>>> when an
>>>>>> action link is created; it might be possible to automatically
>>>>>> add a
>>>>>> query parameter to every link with authentication, and then
>>>>>> provided
>>>>>> filters in the ComponentEventRequestHandler pipeline to enforce
>>>>>> the
>>>>>> check.
>>>>>
>>>>> I finally had time to implement the 'Cross-site request forgery'
>>>>> filter
>>>>> in the way suggested by Howard and it was really simple and
>>>>> straightforward (which shows me again why I think Tapestry is
>>>>> extremely
>>>>> well built). All action links now contain a sid (random generated
>>>>> for
>>>>> each user) and the sid is checked using a
>>>>> ComponentEventRequestFilter.
>>>>> The only possible problem (which was not a problem for me though)
>>>>> could
>>>>> be that the action links now contain an extra parameter
>>>>> (example: ?sid=enn50tk96) which wasn't there before the filter was
>>>>> added. This can interfere with existing code. I was wondering
>>>>> whether it
>>>>> would be possible to remove the sid attribute after checking the
>>>>> sid so
>>>>> the rest of the application has no knowlegde of the sid?
>>>>>
>>>>> Martijn
>>>>>
>>>>>
>>>>> On Mon, 2008-07-28 at 12:27 -0700, Howard Lewis Ship wrote:
>>>>>> I wonder if this could be created as a Mixin?
>>>>>>
>>>>>> Also, the internal LinkFactory service has listeners that know
>>>>>> when an
>>>>>> action link is created; it might be possible to automatically
>>>>>> add a
>>>>>> query parameter to every link with authentication, and then
>>>>>> provided
>>>>>> filters in the ComponentEventRequestHandler pipeline to enforce
>>>>>> the
>>>>>> check.
>>>>>>
>>>>>> On Mon, Jul 28, 2008 at 12:24 PM, Martijn Brinkers (List)
>>>>>> <ma...@gmail.com> wrote:
>>>>>>> Hi Christian,
>>>>>>>
>>>>>>> Do you have some example code of you Form extension?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Martijn
>>>>>>>
>>>>>>> On Mon, 2008-07-28 at 15:18 -0400, Christian Edward Gruber wrote:
>>>>>>>> A good way would be to alter the Form object to contain (via a
>>>>>>>> hidden
>>>>>>>> variable) a field that's generated per the whitepaper linked
>>>>>>>> from that
>>>>>>>> wikipedia article. The form would then consume the post, and if
>>>>>>>> that
>>>>>>>> field is not in the expected state, generate an error state,
>>>>>>>> which
>>>>>>>> could then be redirected to a security page or some such. We
>>>>>>>> solved
>>>>>>>> it this way, though without changing the T5 form object - we
>>>>>>>> used a
>>>>>>>> custom form object.
>>>>>>>>
>>>>>>>> A friend of mine wrote the linked whitepaper, so if someone's
>>>>>>>> trying
>>>>>>>> to put the fix into the Tapestry framework infrastructure, then
>>>>>>>> let me
>>>>>>>> know and I'll connect you by e-mail. It's a good read anyway,
>>>>>>>> as it's
>>>>>>>> a bit of a subtle problem.
>>>>>>>>
>>>>>>>> Christian.
>>>>>>>>
>>>>>>>> On 28-Jul-08, at 14:50 , Martijn Brinkers (List) wrote:
>>>>>>>>
>>>>>>>>> Cross-site request forgeries (CSRF) is a web application
>>>>>> vulnerability
>>>>>>>>> that is often neglected by web developers. If your
>>>>>>>>> application is
>>>>>>>>> vulnerable to CSRF and an attacker can entice you to request
>>>>>>>>> some
>>>>>> URL
>>>>>>>>> (this can be done for example with an image with the src set to
>>>>>>>>> some
>>>>>>>>> Tapestry action) the attacker can execute random Tapestry
>>>>>>>>> actions
>>>>>> and
>>>>>>>>> post forms (like adding a adminitrator etc.) without the users
>>>>>>>>> consent.
>>>>>>>>> For more info on CSRF see for example:
>>>>>>>>> http://en.wikipedia.org/wiki/Cross-site_request_forgery.
>>>>>>>>> One way to protect against CSRF is to add a non-guessable code
>>>>>>>>> (saved in
>>>>>>>>> the user session) to the URLs that need to be protected against
>>>>>>>>> CSRF
>>>>>>>>> or
>>>>>>>>> add a hidden field to a Form with this unique code. When
>>>>>>>>> Tapestry
>>>>>>>>> recieved a request (for a page or action) and that page/action
>>>>>>>>> need
>>>>>>>>> protection a check is done to see if the code from the URL
>>>>>>>>> matches
>>>>>> the
>>>>>>>>> code stored in the user session. If not you know that the
>>>>>>>>> request
>>>>>> did
>>>>>>>>> not generated by tapestry.
>>>>>>>>>
>>>>>>>>> My question is what is the best way to implement this? Should I
>>>>>>>>> add
>>>>>>>>> the
>>>>>>>>> code as a context parameter and for forms as a hidden field?
>>>>>>>>> And use
>>>>>> a
>>>>>>>>> dispatcher to check whether the page should have been
>>>>>>>>> protected?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Martijn Brinkers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/T5%3A-How-to-protect-against-%27Cross-site-request-forgery%27--tp18697003p18845568.html
>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/T5%3A-How-to-protect-against-%27Cross-site-request-forgery%27--tp18697003p18851209.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
--
View this message in context: http://www.nabble.com/T5%3A-How-to-protect-against-%27Cross-site-request-forgery%27--tp18697003p18864393.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: How to protect against 'Cross-site request forgery'?
Posted by Christian Edward Gruber <ch...@gmail.com>.
Incidentally, on Java get and post are the same, unless someone
implements the servlet and overrides post and get. At present, get
and post both direct to the same method. That's bad. But I'm not
saying "trust post", I'm saying that get is worse than post, except
that the above turns them both into the same thing.
Anyway, the article I was referring to (which describes some of the
issues involved with fixing it) is: http://www.isecpartners.com/documents/XSRF_Paper.pdf
The issue with xsrf has to do with application design and actions.
Navigation itself is not an issue, but actions that do something.
As to the issue of using non-cryptographic tokens, it's insane.
Timing/guessing is the root of most exploits and the way to defeat
XSRF is to ensure that the "action formulator" and the "action
receiver" both agree on the number, and that an intervening party that
replays the action can't guess the new number. If you're incrementing
or decrementing on the first number, an attacker only has to try an
increment likely to be too high, then repeat it until the increment
count reaches his selected number.
Anyway, I'm not saying don't do it on every single post, it's just
that it's overkill, overcomplicates urls (because you have to use it
on URLs sometimes), and you need to be able to turn it off where it's
not needed anyway, because new sessions won't have a number, so you
need a starting point where it's turned on. Now maybe that point is a
redirect to an entry point that's known, but that means you can't, by
definition, have direct linking to anything in the application.
Anyway, please read this paper - the solutions are good, and the
framework can enable the solution, but can't solve it for you.
Christian.
On 6-Aug-08, at 09:29 , 9902468 wrote:
>
> I don't think that people should trust post anymore than get.
> Period. They
> should both be regarded as dangerous.
>
> The second issue of placing too much load on server is valid, but
> can be
> lowered as the unique request part in the token can be achieved
> using a
> running number on the generated token, not to generate the whole
> token for
> every request. Granted that user can guess the number easily, but
> there
> really is no harm if user alters the number or the token, then it just
> doesn't match. (Same as your model but the running number added.)
> This does
> add some perfomance penalty, but I believe that it is acceptable.
>
> The point that really critical things should always be confirmed via
> non-computer way is good, but sometimes unacceptable. Then one must
> settle
> to what can be done.
>
> You said "Blanket solutions don't make you secure if they're knee-
> jerk.".
> And I agree. But "...applying broad strokes isn't a good model of
> security,
> in my view." is not right in this context in my opinion. Is there
> harm done
> if token is used in every request (performance questions ignored)?
>
> This solution is not the save-everything by all means, just one tool
> in our
> box.
>
> - 99
>
> Ps. I agree that the capability to have a secure request key be
> built into
> ActionLink, Page, and Form is enough. (Although there could be
> configuration
> symbol which configures the default, thus enabling the default to be
> on or
> off and then developer could override that if needed.)
>
>
> Christian Edward Gruber-2 wrote:
>>
>> Ok, people should read the whitepaper. Part of it describes how http
>> gets and using query parameters are somewhat easier to do request
>> forging on than posts. I have to think through the filter approach,
>> but the big deal is on forms. However, several app design principles
>> also apply - in particular, ensuring that there are no changes that
>> one can make, if one were forged, that don't include notification
>> that
>> the change was made to the original e-mail address of the user.
>>
>> The classic example is on a bank site. If i can forge a request to
>> change the notification e-mail, then can set my own e-mail as the new
>> notification source. THEN I can do all sorts of things, including
>> ask
>> for a password reset and get them to my own address, and take over
>> the
>> account. If, however, such underlying account changes require a
>> phone
>> call, or are protected from forgery, then you dramatically limit the
>> danger of the forgery.
>>
>> The reason I'd not enable this on every single request (especially
>> navigation alone) is that generating a cryptographically valid
>> request
>> key and storing it puts a pretty high burden on a server with any
>> serious load, and having this happen on any and every click can be
>> quite expensive. The only caveat I'd make to that is the fact that
>> T5 uses some parameterization via the URL, and if those parameters
>> are
>> worth forging, then having the solution implemented on clicks as well
>> would be critical.
>>
>> Blanket solutions don't make you secure if they're knee-jerk. You
>> still have to do threat modelling, and incorporate it into the app
>> design. I'd much rather see the capability to have a secure request
>> key be built into ActionLink, Page, and Form, to allow one to enable
>> it with a flag, according to what needs protecting. T5, having the
>> component consume its own data is in a much better place to implement
>> this cleanly in a few key components than Struts or other things.
>> But
>> getting nervous about XSRF (or CSRF or whatever the current acronym
>> is
>> today) and applying broad strokes isn't a good model of security, in
>> my view.
>>
>> Unfortunately, I can't provide source code for our example, as I
>> don't
>> have it any more, and it was client code. I'm in the thick of other
>> source and other issues, so I don't really have time to implement it.
>> I do have a client that may need it, so if I get there before a good
>> general solution is adopted in T5, I'll try to write it in a way that
>> I can share the source with the community.
>>
>> Christian.
>>
>> On 6-Aug-08, at 03:13 , 9902468 wrote:
>>
>>>
>>> Hi,
>>>
>>> CSRF solution could be the base for the solution to my problem,
>>> described
>>> here:
>>>
>>> http://www.nabble.com/T5-double-click---multiple-windows-on-same-session-prevention-to18807447.html
>>>
>>> Could you post the code? I think that I need only to customize it so
>>> that it
>>> changes the sid to every response and accepts only request with the
>>> latest
>>> one.
>>>
>>> I'm also interested of the mixin(s) code. (Or the custom action
>>> link / form
>>> implementation if that approach was chosen.)
>>>
>>> - 99
>>>
>>>
>>> Martijn Brinkers (List)-2 wrote:
>>>>
>>>>> Also, the internal LinkFactory service has listeners that know
>>>>> when an
>>>>> action link is created; it might be possible to automatically
>>>>> add a
>>>>> query parameter to every link with authentication, and then
>>>>> provided
>>>>> filters in the ComponentEventRequestHandler pipeline to enforce
>>>>> the
>>>>> check.
>>>>
>>>> I finally had time to implement the 'Cross-site request forgery'
>>>> filter
>>>> in the way suggested by Howard and it was really simple and
>>>> straightforward (which shows me again why I think Tapestry is
>>>> extremely
>>>> well built). All action links now contain a sid (random generated
>>>> for
>>>> each user) and the sid is checked using a
>>>> ComponentEventRequestFilter.
>>>> The only possible problem (which was not a problem for me though)
>>>> could
>>>> be that the action links now contain an extra parameter
>>>> (example: ?sid=enn50tk96) which wasn't there before the filter was
>>>> added. This can interfere with existing code. I was wondering
>>>> whether it
>>>> would be possible to remove the sid attribute after checking the
>>>> sid so
>>>> the rest of the application has no knowlegde of the sid?
>>>>
>>>> Martijn
>>>>
>>>>
>>>> On Mon, 2008-07-28 at 12:27 -0700, Howard Lewis Ship wrote:
>>>>> I wonder if this could be created as a Mixin?
>>>>>
>>>>> Also, the internal LinkFactory service has listeners that know
>>>>> when an
>>>>> action link is created; it might be possible to automatically
>>>>> add a
>>>>> query parameter to every link with authentication, and then
>>>>> provided
>>>>> filters in the ComponentEventRequestHandler pipeline to enforce
>>>>> the
>>>>> check.
>>>>>
>>>>> On Mon, Jul 28, 2008 at 12:24 PM, Martijn Brinkers (List)
>>>>> <ma...@gmail.com> wrote:
>>>>>> Hi Christian,
>>>>>>
>>>>>> Do you have some example code of you Form extension?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Martijn
>>>>>>
>>>>>> On Mon, 2008-07-28 at 15:18 -0400, Christian Edward Gruber wrote:
>>>>>>> A good way would be to alter the Form object to contain (via a
>>>>>>> hidden
>>>>>>> variable) a field that's generated per the whitepaper linked
>>>>>>> from that
>>>>>>> wikipedia article. The form would then consume the post, and if
>>>>>>> that
>>>>>>> field is not in the expected state, generate an error state,
>>>>>>> which
>>>>>>> could then be redirected to a security page or some such. We
>>>>>>> solved
>>>>>>> it this way, though without changing the T5 form object - we
>>>>>>> used a
>>>>>>> custom form object.
>>>>>>>
>>>>>>> A friend of mine wrote the linked whitepaper, so if someone's
>>>>>>> trying
>>>>>>> to put the fix into the Tapestry framework infrastructure, then
>>>>>>> let me
>>>>>>> know and I'll connect you by e-mail. It's a good read anyway,
>>>>>>> as it's
>>>>>>> a bit of a subtle problem.
>>>>>>>
>>>>>>> Christian.
>>>>>>>
>>>>>>> On 28-Jul-08, at 14:50 , Martijn Brinkers (List) wrote:
>>>>>>>
>>>>>>>> Cross-site request forgeries (CSRF) is a web application
>>>>> vulnerability
>>>>>>>> that is often neglected by web developers. If your
>>>>>>>> application is
>>>>>>>> vulnerable to CSRF and an attacker can entice you to request
>>>>>>>> some
>>>>> URL
>>>>>>>> (this can be done for example with an image with the src set to
>>>>>>>> some
>>>>>>>> Tapestry action) the attacker can execute random Tapestry
>>>>>>>> actions
>>>>> and
>>>>>>>> post forms (like adding a adminitrator etc.) without the users
>>>>>>>> consent.
>>>>>>>> For more info on CSRF see for example:
>>>>>>>> http://en.wikipedia.org/wiki/Cross-site_request_forgery.
>>>>>>>> One way to protect against CSRF is to add a non-guessable code
>>>>>>>> (saved in
>>>>>>>> the user session) to the URLs that need to be protected against
>>>>>>>> CSRF
>>>>>>>> or
>>>>>>>> add a hidden field to a Form with this unique code. When
>>>>>>>> Tapestry
>>>>>>>> recieved a request (for a page or action) and that page/action
>>>>>>>> need
>>>>>>>> protection a check is done to see if the code from the URL
>>>>>>>> matches
>>>>> the
>>>>>>>> code stored in the user session. If not you know that the
>>>>>>>> request
>>>>> did
>>>>>>>> not generated by tapestry.
>>>>>>>>
>>>>>>>> My question is what is the best way to implement this? Should I
>>>>>>>> add
>>>>>>>> the
>>>>>>>> code as a context parameter and for forms as a hidden field?
>>>>>>>> And use
>>>>> a
>>>>>>>> dispatcher to check whether the page should have been
>>>>>>>> protected?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Martijn Brinkers
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/T5%3A-How-to-protect-against-%27Cross-site-request-forgery%27--tp18697003p18845568.html
>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/T5%3A-How-to-protect-against-%27Cross-site-request-forgery%27--tp18697003p18851209.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: T5: How to protect against 'Cross-site request forgery'?
Posted by 9902468 <vi...@cerion.fi>.
I don't think that people should trust post anymore than get. Period. They
should both be regarded as dangerous.
The second issue of placing too much load on server is valid, but can be
lowered as the unique request part in the token can be achieved using a
running number on the generated token, not to generate the whole token for
every request. Granted that user can guess the number easily, but there
really is no harm if user alters the number or the token, then it just
doesn't match. (Same as your model but the running number added.) This does
add some perfomance penalty, but I believe that it is acceptable.
The point that really critical things should always be confirmed via
non-computer way is good, but sometimes unacceptable. Then one must settle
to what can be done.
You said "Blanket solutions don't make you secure if they're knee-jerk.".
And I agree. But "...applying broad strokes isn't a good model of security,
in my view." is not right in this context in my opinion. Is there harm done
if token is used in every request (performance questions ignored)?
This solution is not the save-everything by all means, just one tool in our
box.
- 99
Ps. I agree that the capability to have a secure request key be built into
ActionLink, Page, and Form is enough. (Although there could be configuration
symbol which configures the default, thus enabling the default to be on or
off and then developer could override that if needed.)
Christian Edward Gruber-2 wrote:
>
> Ok, people should read the whitepaper. Part of it describes how http
> gets and using query parameters are somewhat easier to do request
> forging on than posts. I have to think through the filter approach,
> but the big deal is on forms. However, several app design principles
> also apply - in particular, ensuring that there are no changes that
> one can make, if one were forged, that don't include notification that
> the change was made to the original e-mail address of the user.
>
> The classic example is on a bank site. If i can forge a request to
> change the notification e-mail, then can set my own e-mail as the new
> notification source. THEN I can do all sorts of things, including ask
> for a password reset and get them to my own address, and take over the
> account. If, however, such underlying account changes require a phone
> call, or are protected from forgery, then you dramatically limit the
> danger of the forgery.
>
> The reason I'd not enable this on every single request (especially
> navigation alone) is that generating a cryptographically valid request
> key and storing it puts a pretty high burden on a server with any
> serious load, and having this happen on any and every click can be
> quite expensive. The only caveat I'd make to that is the fact that
> T5 uses some parameterization via the URL, and if those parameters are
> worth forging, then having the solution implemented on clicks as well
> would be critical.
>
> Blanket solutions don't make you secure if they're knee-jerk. You
> still have to do threat modelling, and incorporate it into the app
> design. I'd much rather see the capability to have a secure request
> key be built into ActionLink, Page, and Form, to allow one to enable
> it with a flag, according to what needs protecting. T5, having the
> component consume its own data is in a much better place to implement
> this cleanly in a few key components than Struts or other things. But
> getting nervous about XSRF (or CSRF or whatever the current acronym is
> today) and applying broad strokes isn't a good model of security, in
> my view.
>
> Unfortunately, I can't provide source code for our example, as I don't
> have it any more, and it was client code. I'm in the thick of other
> source and other issues, so I don't really have time to implement it.
> I do have a client that may need it, so if I get there before a good
> general solution is adopted in T5, I'll try to write it in a way that
> I can share the source with the community.
>
> Christian.
>
> On 6-Aug-08, at 03:13 , 9902468 wrote:
>
>>
>> Hi,
>>
>> CSRF solution could be the base for the solution to my problem,
>> described
>> here:
>>
>> http://www.nabble.com/T5-double-click---multiple-windows-on-same-session-prevention-to18807447.html
>>
>> Could you post the code? I think that I need only to customize it so
>> that it
>> changes the sid to every response and accepts only request with the
>> latest
>> one.
>>
>> I'm also interested of the mixin(s) code. (Or the custom action
>> link / form
>> implementation if that approach was chosen.)
>>
>> - 99
>>
>>
>> Martijn Brinkers (List)-2 wrote:
>>>
>>>> Also, the internal LinkFactory service has listeners that know
>>>> when an
>>>> action link is created; it might be possible to automatically add a
>>>> query parameter to every link with authentication, and then provided
>>>> filters in the ComponentEventRequestHandler pipeline to enforce the
>>>> check.
>>>
>>> I finally had time to implement the 'Cross-site request forgery'
>>> filter
>>> in the way suggested by Howard and it was really simple and
>>> straightforward (which shows me again why I think Tapestry is
>>> extremely
>>> well built). All action links now contain a sid (random generated for
>>> each user) and the sid is checked using a
>>> ComponentEventRequestFilter.
>>> The only possible problem (which was not a problem for me though)
>>> could
>>> be that the action links now contain an extra parameter
>>> (example: ?sid=enn50tk96) which wasn't there before the filter was
>>> added. This can interfere with existing code. I was wondering
>>> whether it
>>> would be possible to remove the sid attribute after checking the
>>> sid so
>>> the rest of the application has no knowlegde of the sid?
>>>
>>> Martijn
>>>
>>>
>>> On Mon, 2008-07-28 at 12:27 -0700, Howard Lewis Ship wrote:
>>>> I wonder if this could be created as a Mixin?
>>>>
>>>> Also, the internal LinkFactory service has listeners that know
>>>> when an
>>>> action link is created; it might be possible to automatically add a
>>>> query parameter to every link with authentication, and then provided
>>>> filters in the ComponentEventRequestHandler pipeline to enforce the
>>>> check.
>>>>
>>>> On Mon, Jul 28, 2008 at 12:24 PM, Martijn Brinkers (List)
>>>> <ma...@gmail.com> wrote:
>>>>> Hi Christian,
>>>>>
>>>>> Do you have some example code of you Form extension?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Martijn
>>>>>
>>>>> On Mon, 2008-07-28 at 15:18 -0400, Christian Edward Gruber wrote:
>>>>>> A good way would be to alter the Form object to contain (via a
>>>>>> hidden
>>>>>> variable) a field that's generated per the whitepaper linked
>>>>>> from that
>>>>>> wikipedia article. The form would then consume the post, and if
>>>>>> that
>>>>>> field is not in the expected state, generate an error state, which
>>>>>> could then be redirected to a security page or some such. We
>>>>>> solved
>>>>>> it this way, though without changing the T5 form object - we
>>>>>> used a
>>>>>> custom form object.
>>>>>>
>>>>>> A friend of mine wrote the linked whitepaper, so if someone's
>>>>>> trying
>>>>>> to put the fix into the Tapestry framework infrastructure, then
>>>>>> let me
>>>>>> know and I'll connect you by e-mail. It's a good read anyway,
>>>>>> as it's
>>>>>> a bit of a subtle problem.
>>>>>>
>>>>>> Christian.
>>>>>>
>>>>>> On 28-Jul-08, at 14:50 , Martijn Brinkers (List) wrote:
>>>>>>
>>>>>>> Cross-site request forgeries (CSRF) is a web application
>>>> vulnerability
>>>>>>> that is often neglected by web developers. If your application is
>>>>>>> vulnerable to CSRF and an attacker can entice you to request some
>>>> URL
>>>>>>> (this can be done for example with an image with the src set to
>>>>>>> some
>>>>>>> Tapestry action) the attacker can execute random Tapestry actions
>>>> and
>>>>>>> post forms (like adding a adminitrator etc.) without the users
>>>>>>> consent.
>>>>>>> For more info on CSRF see for example:
>>>>>>> http://en.wikipedia.org/wiki/Cross-site_request_forgery.
>>>>>>> One way to protect against CSRF is to add a non-guessable code
>>>>>>> (saved in
>>>>>>> the user session) to the URLs that need to be protected against
>>>>>>> CSRF
>>>>>>> or
>>>>>>> add a hidden field to a Form with this unique code. When Tapestry
>>>>>>> recieved a request (for a page or action) and that page/action
>>>>>>> need
>>>>>>> protection a check is done to see if the code from the URL
>>>>>>> matches
>>>> the
>>>>>>> code stored in the user session. If not you know that the request
>>>> did
>>>>>>> not generated by tapestry.
>>>>>>>
>>>>>>> My question is what is the best way to implement this? Should I
>>>>>>> add
>>>>>>> the
>>>>>>> code as a context parameter and for forms as a hidden field?
>>>>>>> And use
>>>> a
>>>>>>> dispatcher to check whether the page should have been protected?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Martijn Brinkers
>>>>>>>
>>>>>>>
>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/T5%3A-How-to-protect-against-%27Cross-site-request-forgery%27--tp18697003p18845568.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
--
View this message in context: http://www.nabble.com/T5%3A-How-to-protect-against-%27Cross-site-request-forgery%27--tp18697003p18851209.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: How to protect against 'Cross-site request forgery'?
Posted by Christian Edward Gruber <ch...@gmail.com>.
Ok, people should read the whitepaper. Part of it describes how http
gets and using query parameters are somewhat easier to do request
forging on than posts. I have to think through the filter approach,
but the big deal is on forms. However, several app design principles
also apply - in particular, ensuring that there are no changes that
one can make, if one were forged, that don't include notification that
the change was made to the original e-mail address of the user.
The classic example is on a bank site. If i can forge a request to
change the notification e-mail, then can set my own e-mail as the new
notification source. THEN I can do all sorts of things, including ask
for a password reset and get them to my own address, and take over the
account. If, however, such underlying account changes require a phone
call, or are protected from forgery, then you dramatically limit the
danger of the forgery.
The reason I'd not enable this on every single request (especially
navigation alone) is that generating a cryptographically valid request
key and storing it puts a pretty high burden on a server with any
serious load, and having this happen on any and every click can be
quite expensive. The only caveat I'd make to that is the fact that
T5 uses some parameterization via the URL, and if those parameters are
worth forging, then having the solution implemented on clicks as well
would be critical.
Blanket solutions don't make you secure if they're knee-jerk. You
still have to do threat modelling, and incorporate it into the app
design. I'd much rather see the capability to have a secure request
key be built into ActionLink, Page, and Form, to allow one to enable
it with a flag, according to what needs protecting. T5, having the
component consume its own data is in a much better place to implement
this cleanly in a few key components than Struts or other things. But
getting nervous about XSRF (or CSRF or whatever the current acronym is
today) and applying broad strokes isn't a good model of security, in
my view.
Unfortunately, I can't provide source code for our example, as I don't
have it any more, and it was client code. I'm in the thick of other
source and other issues, so I don't really have time to implement it.
I do have a client that may need it, so if I get there before a good
general solution is adopted in T5, I'll try to write it in a way that
I can share the source with the community.
Christian.
On 6-Aug-08, at 03:13 , 9902468 wrote:
>
> Hi,
>
> CSRF solution could be the base for the solution to my problem,
> described
> here:
>
> http://www.nabble.com/T5-double-click---multiple-windows-on-same-session-prevention-to18807447.html
>
> Could you post the code? I think that I need only to customize it so
> that it
> changes the sid to every response and accepts only request with the
> latest
> one.
>
> I'm also interested of the mixin(s) code. (Or the custom action
> link / form
> implementation if that approach was chosen.)
>
> - 99
>
>
> Martijn Brinkers (List)-2 wrote:
>>
>>> Also, the internal LinkFactory service has listeners that know
>>> when an
>>> action link is created; it might be possible to automatically add a
>>> query parameter to every link with authentication, and then provided
>>> filters in the ComponentEventRequestHandler pipeline to enforce the
>>> check.
>>
>> I finally had time to implement the 'Cross-site request forgery'
>> filter
>> in the way suggested by Howard and it was really simple and
>> straightforward (which shows me again why I think Tapestry is
>> extremely
>> well built). All action links now contain a sid (random generated for
>> each user) and the sid is checked using a
>> ComponentEventRequestFilter.
>> The only possible problem (which was not a problem for me though)
>> could
>> be that the action links now contain an extra parameter
>> (example: ?sid=enn50tk96) which wasn't there before the filter was
>> added. This can interfere with existing code. I was wondering
>> whether it
>> would be possible to remove the sid attribute after checking the
>> sid so
>> the rest of the application has no knowlegde of the sid?
>>
>> Martijn
>>
>>
>> On Mon, 2008-07-28 at 12:27 -0700, Howard Lewis Ship wrote:
>>> I wonder if this could be created as a Mixin?
>>>
>>> Also, the internal LinkFactory service has listeners that know
>>> when an
>>> action link is created; it might be possible to automatically add a
>>> query parameter to every link with authentication, and then provided
>>> filters in the ComponentEventRequestHandler pipeline to enforce the
>>> check.
>>>
>>> On Mon, Jul 28, 2008 at 12:24 PM, Martijn Brinkers (List)
>>> <ma...@gmail.com> wrote:
>>>> Hi Christian,
>>>>
>>>> Do you have some example code of you Form extension?
>>>>
>>>> Thanks,
>>>>
>>>> Martijn
>>>>
>>>> On Mon, 2008-07-28 at 15:18 -0400, Christian Edward Gruber wrote:
>>>>> A good way would be to alter the Form object to contain (via a
>>>>> hidden
>>>>> variable) a field that's generated per the whitepaper linked
>>>>> from that
>>>>> wikipedia article. The form would then consume the post, and if
>>>>> that
>>>>> field is not in the expected state, generate an error state, which
>>>>> could then be redirected to a security page or some such. We
>>>>> solved
>>>>> it this way, though without changing the T5 form object - we
>>>>> used a
>>>>> custom form object.
>>>>>
>>>>> A friend of mine wrote the linked whitepaper, so if someone's
>>>>> trying
>>>>> to put the fix into the Tapestry framework infrastructure, then
>>>>> let me
>>>>> know and I'll connect you by e-mail. It's a good read anyway,
>>>>> as it's
>>>>> a bit of a subtle problem.
>>>>>
>>>>> Christian.
>>>>>
>>>>> On 28-Jul-08, at 14:50 , Martijn Brinkers (List) wrote:
>>>>>
>>>>>> Cross-site request forgeries (CSRF) is a web application
>>> vulnerability
>>>>>> that is often neglected by web developers. If your application is
>>>>>> vulnerable to CSRF and an attacker can entice you to request some
>>> URL
>>>>>> (this can be done for example with an image with the src set to
>>>>>> some
>>>>>> Tapestry action) the attacker can execute random Tapestry actions
>>> and
>>>>>> post forms (like adding a adminitrator etc.) without the users
>>>>>> consent.
>>>>>> For more info on CSRF see for example:
>>>>>> http://en.wikipedia.org/wiki/Cross-site_request_forgery.
>>>>>> One way to protect against CSRF is to add a non-guessable code
>>>>>> (saved in
>>>>>> the user session) to the URLs that need to be protected against
>>>>>> CSRF
>>>>>> or
>>>>>> add a hidden field to a Form with this unique code. When Tapestry
>>>>>> recieved a request (for a page or action) and that page/action
>>>>>> need
>>>>>> protection a check is done to see if the code from the URL
>>>>>> matches
>>> the
>>>>>> code stored in the user session. If not you know that the request
>>> did
>>>>>> not generated by tapestry.
>>>>>>
>>>>>> My question is what is the best way to implement this? Should I
>>>>>> add
>>>>>> the
>>>>>> code as a context parameter and for forms as a hidden field?
>>>>>> And use
>>> a
>>>>>> dispatcher to check whether the page should have been protected?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Martijn Brinkers
>>>>>>
>>>>>>
>>>>>>
>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/T5%3A-How-to-protect-against-%27Cross-site-request-forgery%27--tp18697003p18845568.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: T5: How to protect against 'Cross-site request forgery'?
Posted by 9902468 <vi...@cerion.fi>.
Thank you!
This is something I can use and extend.
- 99
Martijn Brinkers (List)-2 wrote:
>
> I have added a howto
>
> http://wiki.apache.org/tapestry/Tapestry5CSRF
>
> Martijn
>
> On Wed, 2008-08-06 at 00:13 -0700, 9902468 wrote:
>> Hi,
>>
>> CSRF solution could be the base for the solution to my problem, described
>> here:
>>
>> http://www.nabble.com/T5-double-click---multiple-windows-on-same-session-prevention-to18807447.html
>>
>> Could you post the code? I think that I need only to customize it so that
>> it
>> changes the sid to every response and accepts only request with the
>> latest
>> one.
>>
>> I'm also interested of the mixin(s) code. (Or the custom action link /
>> form
>> implementation if that approach was chosen.)
>>
>> - 99
>>
>>
>> Martijn Brinkers (List)-2 wrote:
>> >
>> >> Also, the internal LinkFactory service has listeners that know when an
>> >> action link is created; it might be possible to automatically add a
>> >> query parameter to every link with authentication, and then provided
>> >> filters in the ComponentEventRequestHandler pipeline to enforce the
>> >> check.
>> >
>> > I finally had time to implement the 'Cross-site request forgery' filter
>> > in the way suggested by Howard and it was really simple and
>> > straightforward (which shows me again why I think Tapestry is extremely
>> > well built). All action links now contain a sid (random generated for
>> > each user) and the sid is checked using a ComponentEventRequestFilter.
>> > The only possible problem (which was not a problem for me though) could
>> > be that the action links now contain an extra parameter
>> > (example: ?sid=enn50tk96) which wasn't there before the filter was
>> > added. This can interfere with existing code. I was wondering whether
>> it
>> > would be possible to remove the sid attribute after checking the sid so
>> > the rest of the application has no knowlegde of the sid?
>> >
>> > Martijn
>> >
>> >
>> > On Mon, 2008-07-28 at 12:27 -0700, Howard Lewis Ship wrote:
>> >> I wonder if this could be created as a Mixin?
>> >>
>> >> Also, the internal LinkFactory service has listeners that know when an
>> >> action link is created; it might be possible to automatically add a
>> >> query parameter to every link with authentication, and then provided
>> >> filters in the ComponentEventRequestHandler pipeline to enforce the
>> >> check.
>> >>
>> >> On Mon, Jul 28, 2008 at 12:24 PM, Martijn Brinkers (List)
>> >> <ma...@gmail.com> wrote:
>> >> > Hi Christian,
>> >> >
>> >> > Do you have some example code of you Form extension?
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Martijn
>> >> >
>> >> > On Mon, 2008-07-28 at 15:18 -0400, Christian Edward Gruber wrote:
>> >> >> A good way would be to alter the Form object to contain (via a
>> hidden
>> >> >> variable) a field that's generated per the whitepaper linked from
>> that
>> >> >> wikipedia article. The form would then consume the post, and if
>> that
>> >> >> field is not in the expected state, generate an error state, which
>> >> >> could then be redirected to a security page or some such. We
>> solved
>> >> >> it this way, though without changing the T5 form object - we used a
>> >> >> custom form object.
>> >> >>
>> >> >> A friend of mine wrote the linked whitepaper, so if someone's
>> trying
>> >> >> to put the fix into the Tapestry framework infrastructure, then let
>> me
>> >> >> know and I'll connect you by e-mail. It's a good read anyway, as
>> it's
>> >> >> a bit of a subtle problem.
>> >> >>
>> >> >> Christian.
>> >> >>
>> >> >> On 28-Jul-08, at 14:50 , Martijn Brinkers (List) wrote:
>> >> >>
>> >> >> > Cross-site request forgeries (CSRF) is a web application
>> >> vulnerability
>> >> >> > that is often neglected by web developers. If your application is
>> >> >> > vulnerable to CSRF and an attacker can entice you to request some
>> >> URL
>> >> >> > (this can be done for example with an image with the src set to
>> some
>> >> >> > Tapestry action) the attacker can execute random Tapestry actions
>> >> and
>> >> >> > post forms (like adding a adminitrator etc.) without the users
>> >> >> > consent.
>> >> >> > For more info on CSRF see for example:
>> >> >> > http://en.wikipedia.org/wiki/Cross-site_request_forgery.
>> >> >> > One way to protect against CSRF is to add a non-guessable code
>> >> >> > (saved in
>> >> >> > the user session) to the URLs that need to be protected against
>> CSRF
>> >> >> > or
>> >> >> > add a hidden field to a Form with this unique code. When Tapestry
>> >> >> > recieved a request (for a page or action) and that page/action
>> need
>> >> >> > protection a check is done to see if the code from the URL
>> matches
>> >> the
>> >> >> > code stored in the user session. If not you know that the request
>> >> did
>> >> >> > not generated by tapestry.
>> >> >> >
>> >> >> > My question is what is the best way to implement this? Should I
>> add
>> >> >> > the
>> >> >> > code as a context parameter and for forms as a hidden field? And
>> use
>> >> a
>> >> >> > dispatcher to check whether the page should have been protected?
>> >> >> >
>> >> >> > Thanks,
>> >> >> >
>> >> >> > Martijn Brinkers
>> >> >> >
>> >> >> >
>> >> >> >
>> >> ---------------------------------------------------------------------
>> >> >> > 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
>> >> >>
>> >> >
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > 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
>> >
>> >
>> >
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/T5%3A-How-to-protect-against-%27Cross-site-request-forgery%27--tp18697003p18864428.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: How to protect against 'Cross-site request forgery'?
Posted by "Martijn Brinkers (List)" <ma...@gmail.com>.
I have added a howto
http://wiki.apache.org/tapestry/Tapestry5CSRF
Martijn
On Wed, 2008-08-06 at 00:13 -0700, 9902468 wrote:
> Hi,
>
> CSRF solution could be the base for the solution to my problem, described
> here:
>
> http://www.nabble.com/T5-double-click---multiple-windows-on-same-session-prevention-to18807447.html
>
> Could you post the code? I think that I need only to customize it so that it
> changes the sid to every response and accepts only request with the latest
> one.
>
> I'm also interested of the mixin(s) code. (Or the custom action link / form
> implementation if that approach was chosen.)
>
> - 99
>
>
> Martijn Brinkers (List)-2 wrote:
> >
> >> Also, the internal LinkFactory service has listeners that know when an
> >> action link is created; it might be possible to automatically add a
> >> query parameter to every link with authentication, and then provided
> >> filters in the ComponentEventRequestHandler pipeline to enforce the
> >> check.
> >
> > I finally had time to implement the 'Cross-site request forgery' filter
> > in the way suggested by Howard and it was really simple and
> > straightforward (which shows me again why I think Tapestry is extremely
> > well built). All action links now contain a sid (random generated for
> > each user) and the sid is checked using a ComponentEventRequestFilter.
> > The only possible problem (which was not a problem for me though) could
> > be that the action links now contain an extra parameter
> > (example: ?sid=enn50tk96) which wasn't there before the filter was
> > added. This can interfere with existing code. I was wondering whether it
> > would be possible to remove the sid attribute after checking the sid so
> > the rest of the application has no knowlegde of the sid?
> >
> > Martijn
> >
> >
> > On Mon, 2008-07-28 at 12:27 -0700, Howard Lewis Ship wrote:
> >> I wonder if this could be created as a Mixin?
> >>
> >> Also, the internal LinkFactory service has listeners that know when an
> >> action link is created; it might be possible to automatically add a
> >> query parameter to every link with authentication, and then provided
> >> filters in the ComponentEventRequestHandler pipeline to enforce the
> >> check.
> >>
> >> On Mon, Jul 28, 2008 at 12:24 PM, Martijn Brinkers (List)
> >> <ma...@gmail.com> wrote:
> >> > Hi Christian,
> >> >
> >> > Do you have some example code of you Form extension?
> >> >
> >> > Thanks,
> >> >
> >> > Martijn
> >> >
> >> > On Mon, 2008-07-28 at 15:18 -0400, Christian Edward Gruber wrote:
> >> >> A good way would be to alter the Form object to contain (via a hidden
> >> >> variable) a field that's generated per the whitepaper linked from that
> >> >> wikipedia article. The form would then consume the post, and if that
> >> >> field is not in the expected state, generate an error state, which
> >> >> could then be redirected to a security page or some such. We solved
> >> >> it this way, though without changing the T5 form object - we used a
> >> >> custom form object.
> >> >>
> >> >> A friend of mine wrote the linked whitepaper, so if someone's trying
> >> >> to put the fix into the Tapestry framework infrastructure, then let me
> >> >> know and I'll connect you by e-mail. It's a good read anyway, as it's
> >> >> a bit of a subtle problem.
> >> >>
> >> >> Christian.
> >> >>
> >> >> On 28-Jul-08, at 14:50 , Martijn Brinkers (List) wrote:
> >> >>
> >> >> > Cross-site request forgeries (CSRF) is a web application
> >> vulnerability
> >> >> > that is often neglected by web developers. If your application is
> >> >> > vulnerable to CSRF and an attacker can entice you to request some
> >> URL
> >> >> > (this can be done for example with an image with the src set to some
> >> >> > Tapestry action) the attacker can execute random Tapestry actions
> >> and
> >> >> > post forms (like adding a adminitrator etc.) without the users
> >> >> > consent.
> >> >> > For more info on CSRF see for example:
> >> >> > http://en.wikipedia.org/wiki/Cross-site_request_forgery.
> >> >> > One way to protect against CSRF is to add a non-guessable code
> >> >> > (saved in
> >> >> > the user session) to the URLs that need to be protected against CSRF
> >> >> > or
> >> >> > add a hidden field to a Form with this unique code. When Tapestry
> >> >> > recieved a request (for a page or action) and that page/action need
> >> >> > protection a check is done to see if the code from the URL matches
> >> the
> >> >> > code stored in the user session. If not you know that the request
> >> did
> >> >> > not generated by tapestry.
> >> >> >
> >> >> > My question is what is the best way to implement this? Should I add
> >> >> > the
> >> >> > code as a context parameter and for forms as a hidden field? And use
> >> a
> >> >> > dispatcher to check whether the page should have been protected?
> >> >> >
> >> >> > Thanks,
> >> >> >
> >> >> > Martijn Brinkers
> >> >> >
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > 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
> >> >>
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > 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
> >
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: How to protect against 'Cross-site request forgery'?
Posted by 9902468 <vi...@cerion.fi>.
Hi,
CSRF solution could be the base for the solution to my problem, described
here:
http://www.nabble.com/T5-double-click---multiple-windows-on-same-session-prevention-to18807447.html
Could you post the code? I think that I need only to customize it so that it
changes the sid to every response and accepts only request with the latest
one.
I'm also interested of the mixin(s) code. (Or the custom action link / form
implementation if that approach was chosen.)
- 99
Martijn Brinkers (List)-2 wrote:
>
>> Also, the internal LinkFactory service has listeners that know when an
>> action link is created; it might be possible to automatically add a
>> query parameter to every link with authentication, and then provided
>> filters in the ComponentEventRequestHandler pipeline to enforce the
>> check.
>
> I finally had time to implement the 'Cross-site request forgery' filter
> in the way suggested by Howard and it was really simple and
> straightforward (which shows me again why I think Tapestry is extremely
> well built). All action links now contain a sid (random generated for
> each user) and the sid is checked using a ComponentEventRequestFilter.
> The only possible problem (which was not a problem for me though) could
> be that the action links now contain an extra parameter
> (example: ?sid=enn50tk96) which wasn't there before the filter was
> added. This can interfere with existing code. I was wondering whether it
> would be possible to remove the sid attribute after checking the sid so
> the rest of the application has no knowlegde of the sid?
>
> Martijn
>
>
> On Mon, 2008-07-28 at 12:27 -0700, Howard Lewis Ship wrote:
>> I wonder if this could be created as a Mixin?
>>
>> Also, the internal LinkFactory service has listeners that know when an
>> action link is created; it might be possible to automatically add a
>> query parameter to every link with authentication, and then provided
>> filters in the ComponentEventRequestHandler pipeline to enforce the
>> check.
>>
>> On Mon, Jul 28, 2008 at 12:24 PM, Martijn Brinkers (List)
>> <ma...@gmail.com> wrote:
>> > Hi Christian,
>> >
>> > Do you have some example code of you Form extension?
>> >
>> > Thanks,
>> >
>> > Martijn
>> >
>> > On Mon, 2008-07-28 at 15:18 -0400, Christian Edward Gruber wrote:
>> >> A good way would be to alter the Form object to contain (via a hidden
>> >> variable) a field that's generated per the whitepaper linked from that
>> >> wikipedia article. The form would then consume the post, and if that
>> >> field is not in the expected state, generate an error state, which
>> >> could then be redirected to a security page or some such. We solved
>> >> it this way, though without changing the T5 form object - we used a
>> >> custom form object.
>> >>
>> >> A friend of mine wrote the linked whitepaper, so if someone's trying
>> >> to put the fix into the Tapestry framework infrastructure, then let me
>> >> know and I'll connect you by e-mail. It's a good read anyway, as it's
>> >> a bit of a subtle problem.
>> >>
>> >> Christian.
>> >>
>> >> On 28-Jul-08, at 14:50 , Martijn Brinkers (List) wrote:
>> >>
>> >> > Cross-site request forgeries (CSRF) is a web application
>> vulnerability
>> >> > that is often neglected by web developers. If your application is
>> >> > vulnerable to CSRF and an attacker can entice you to request some
>> URL
>> >> > (this can be done for example with an image with the src set to some
>> >> > Tapestry action) the attacker can execute random Tapestry actions
>> and
>> >> > post forms (like adding a adminitrator etc.) without the users
>> >> > consent.
>> >> > For more info on CSRF see for example:
>> >> > http://en.wikipedia.org/wiki/Cross-site_request_forgery.
>> >> > One way to protect against CSRF is to add a non-guessable code
>> >> > (saved in
>> >> > the user session) to the URLs that need to be protected against CSRF
>> >> > or
>> >> > add a hidden field to a Form with this unique code. When Tapestry
>> >> > recieved a request (for a page or action) and that page/action need
>> >> > protection a check is done to see if the code from the URL matches
>> the
>> >> > code stored in the user session. If not you know that the request
>> did
>> >> > not generated by tapestry.
>> >> >
>> >> > My question is what is the best way to implement this? Should I add
>> >> > the
>> >> > code as a context parameter and for forms as a hidden field? And use
>> a
>> >> > dispatcher to check whether the page should have been protected?
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Martijn Brinkers
>> >> >
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > 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
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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
>
>
>
--
View this message in context: http://www.nabble.com/T5%3A-How-to-protect-against-%27Cross-site-request-forgery%27--tp18697003p18845568.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org