I'm sure it's understood to most of us on the list that no one thing can ensure security, and that security is a process not a technology or product. And I am sure that most of us on this list are aware of the idea of "point of diminishing returns". For those who don't it means that the time/money one spends to secure something begins to exceed the value of the thing being protected.
Of course good design up front helps us quite a bit with ensuring the security of our applications. But for many reasons, we inherit applications that must be maintained that did not have good planning in place at the time. Or else the assumptions on the project design when that project was started are no longer true. That means that we are faced with doing a cost/benefit analysis as to whether to rebuild, change or kill an application that needs new features/functions in order to continue to be relevant. We have to advise our clients as what is the best way to go, and we have to be (at least) mostly right. As we see, <@USERREFERENCEARGUMENT> by itself is very fallible. Cookies, for the browsers that support them, are better. Caching proxy servers can a bad thing. NAT changes the relative structure of the Internet. People don't want to have to remember logins for every site that they might ever visit. And yet in spite of these limitations, and others, we have to build secure and reliable applications in a timely and inexpensive manor. Tango/Witango helps us with this, but at the end of the day it is still a tool. We, the developers, are the masters. And so we exchange our thoughts here on this list in order that we all become wiser. Eric, I don't know what your budget or timeline or requirements are, and I don't know how the current code is structured. Therefore I cannot recommend the one strategy that will be best for you. I can tell you that you've received many good ideas on the list so far. In fact I may use one or two of these ideas myself in future projects. My point is that no "one" thing is likely to work, especially now. You are most likely going to need a combinations of approaches to address not only the current situation of session hijacking, but to address future potential outbreaks as well. I agree that it is prudent to re-direct users coming into your site with the known userreference argument so that they can get their own userreference number. And I agree that it is not too much to ask that users use a browser that use session Cookies. Perhaps it was a few years ago, but these assumptions change over time. And I think that it is worthwhile to build a cookie test into each application file; you may instead design the application to simply fail if there is no support for session Cookies. I don't know what the "right" answer or answers for are is/are, but I do know that you shouldn't need to make the thing unusable to be secure enough. I have to get back to work now... Anthony - -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Shelley Sent: Thursday, September 12, 2002 1:57 PM To: Multiple recipients of list witango-talk Subject: RE: Witango-Talk: Preventing Session hijacking If you're running a secure application it's a good idea to check the referer on every hit, and if it's not from your site, then purge the user scope and call your login method. This helps to prevent people from hacking your forms and changing values. If your application is structured to use a main taf or tml file, or uses a common initialization method, then your code needs to be in one place only. This won't guarantee security by itself however as a good hacker can spoof a referer. Dave. ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
