Hi John, > Thanks for all the comments.
You're welcome :-) > Yes, I was using a post argument > userreference argument, which I will take out of the taf, When Phil fixed 062 and the management of the UserReference value - it was disclosed that UserReference values passed by Post arguments where not actually working in Tango/Witango. So in fact your system was relying on "session-cookies" - which is safer anyway in my opinion. > but it would > have been hard to spoof on the command line. It's harder, but still not impossible. > I'll ask the student what > was going on for him during the session--that may shed a light on it. > > But I also had an interesting case with another student who logged in > to > the site, started filling out the form, then decided it was time for > lunch, closed his laptop, came back 31 minutes later, finished the form > and posted it, but of course by then the user variables had expired, > but > the session variable was still alive (since obviously he didn't close > the browser). So for persistence of user variables, I'm thinking of > using a hidden input field on the form to maintain the student ID. Or > would this be better as a cookie? It's better to store the Student ID as a User Scope Variable - so the value stays on the Server and never gets exposed to the Internet. The UserReference value stored as a session-cookie is about as safe as you can get, because it's only a reference number to a particular collection of variables stored on your server - and not the data itself. At the basic level, for TAF files that interact with User Variables, you should have a check-point IF Action near the beginning of the TAF that checks the existence of a particular User variable (e.g., <@USER user$studentID>) - if a value is present; then let them pass, if not; then redirect them to a logon prompt or something. By default, Witango handles issuing UserReference "session-cookies" automatically, you just have to ensure you're checking for that particular "valid" User Scope variable (that you assign during their logon) to verify their "rights" to interact with the TAF on the Server. Session management can be a beast, but it is easier to manage if you don't use the <@USERREFERENCEARGUMENT> Meta Tag (in my opinion). Sorry if my comments seem redundant, because I know you know a lot of this already John, but when it comes to security issues I just want to make sure I'm being clear as possible. Hope this helps. Cheers...... > Session management is quite the mind field! > > John > > -----Original Message----- > From: Scott Cadillac [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 14, 2003 1:47 PM > To: [EMAIL PROTECTED] > Subject: Re: Witango-Talk: witango session cookie question > > > Hi John, > > I noticed this behavior a long time ago, where a User's IP address > could > > change, but still maintain Session State. > > Although 062 introduced some changes to how Sessions and UserReference > keys are managed in Witango (to make them more secure), I don't know > about the case where a User's IP address has changed in the middle of a > valid session. > > IP addresses are less reliable than session-cookies for uniquely > identifying an individual, but it can be a factor in terms of security. > > It's a good question. > > The circumstances for this should be rare: > > ~~ The User's ISP uses dynamic addresses - and the dynamic IP > allocation > > happened while the User was in the middle of a Session. Innocent > circumstance. > > ~~ A new User got a copied URL containing someone else's _UserReference > argument, so now they are accidently hijacking/tailgating a Session > from > > a different IP then the original User. 062 addresses this. > > ~~ A hacker has intercepted the UserReference key with a Network > Sniffer > > and is now delibaretly hijacking a session, and the hacker's IP is > different. Of course, a really "good" hacker would spoof their IP > address > to match the original. Rare, but possible. > > If you think it's happening more often than you like - then maybe a new > security routine is in order for your application. > > Like recording the original IP address when a User logs in - then > periodically checking that the User is still coming from the original > IP > > address, if not, then purge the session.... > > Maybe another option in this case, might be to investigate the USERKEY > configuration setting in the witango.ini file?? > > ---- > As for when you're doing an upgrade, I typically un-install the old > version before installing the latest build. > > > Maybe I generated more questions than answers, but I hope this helps. > Cheers..... > > Scott Cadillac, > XML-Extranet - http://xmlx.ca > 403-281-6090 - [EMAIL PROTECTED] > Well-formed Development > -- > Extranet solutions using C# .NET, Witango, MSIE and XML > > > -----Original Message----- > From: "John Newsom" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Date: Tue, 14 Oct 2003 11:43:10 -0700 > Subject: Witango-Talk: witango session cookie question > > > I noticed a bizarre occurance in my witango server log. The IP > > address of the logged on user changed, but the session cookie stayed > > the same. Attached is an excerpt from the log. > > > > We are running .054 version of Witango Server on a Win2K server, > using > > > IIS as the web server. Is this the kind of issue fixed in the .062 > > release? > > > > Second question. To install the .062 update, should the previous > > installation be removed? I tried to do the modify option in the > > installer, but the .dll file didn't change. > > > > Thanks, and I hope these questions weren't answered in previous > posts! > > > I looked in the archives, but nothing precisely fit. > > > > John Newsom > > > > > > > ______________________________________________________________________ > > _ > > _ > > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > _______________________________________________________________________ > _ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > > _______________________________________________________________________ > _ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
