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) >>>> <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> -- >> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
