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) >>>>>> <[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] >> > > > --------------------------------------------------------------------- > 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--tp18697003p18864393.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]
