Hi Eric, Although I've been flamed about this in the past, Mike's points are valid.
I only use 'session-cookies' and not <@USERREFERENCEARGUMENTS> in URLs, and I feel my applications are much more secure. Granted, I only allow MSIE 5.0 or higher (with 'session-cookies' enabled) into my applications, but the point is that all modern browsers know the difference between 'session-cookies' and regular cookies. In order for 'session-cookies' to be disabled, a user has to deliberating hunt for the setting and turn it off - which is a different setting than regular cookies. A quick run down of the difference is: -- 'session-cookies' by definition, are only valid for the current domain and only exist in memory and are NOT written to the user's harddrive. 'session-cookies' are automatically purged when the first Browser window that opens a particular site is closed. -- Regular cookies have configured domains and/or directories and specified expiry time-outs and are subsequently written to the hard-drive and can potentially live on your harddrive forever. Witango (all version from 3.6 and up that I know of) will automatically set a 'session-cookie' for you, that contains the <@USERREFERENCE> value - no work involved on your part. The exception to the above, is if you use a custom local$httpHeader assignment, because this will overwrite the 'session-cookie' assignment, unless you specifically include it. Witango has a specific MetaTag for this, as seen in my example code below (this example also includes purging proxy and browser caches not implemented with normal development): <@ASSIGN local$httpHeader VALUE="Content-Type: text/html<@CRLF>Cache-Control: no-cache, max-age=0, must-revalidate, proxy-revalidate<@CRLF>Pragma: no-cache<@CRLF><@USERREFERENCECOOKIE><@CRLF>"> I recommend reading up on the <@USERREFERENCECOOKIE> MetaTag. I'm not telling you to code this way, just providing my approach to "preventing session hijacking". Hope this helps. Cheers... ----- Original Message ----- From: "Mike Tyranski" <[EMAIL PROTECTED]> To: "Multiple recipients of list witango-talk" <[EMAIL PROTECTED]> Sent: Thursday, September 12, 2002 9:38 AM Subject: Re: Witango-Talk: Preventing Session hijacking > Eric, > > Are they accessing the site and then immediately emailing others the > link? I would think if you tried to use a link where the user reference > was more than X minutes old, that particular user reference would have > expired. In other words, you shouldn't be able to use that link > indefinitely. How do you know if a particular user reference is valid? > IMHO, if they don't have session cookies turned on, they aren't living > in this decade. Passing user references like this is a maintenance > nightmare. > > Mike > > Eric Weidl wrote: > > > > Hi, > > > > Has anyone got any solutions for preventing session hijacking in Tango? > > > > To handle the possibility of a user having cookies turned off, we've made > > sure <@USERREFERENCEARGUMENT> is added to every URL. That solution has > > worked well, until recently. > > > > One of our customers copied a URL from the site and emailed it to a number > > of other people. Now, they are all sharing the same session and user > > variables. > > > > We've always known this could happen but, only with a recent increase in > > traffic on the site have two users come in during the same timeframe (and > > thus stomped on each others variables). > > > > We've got a couple ideas about how to address the problem, but I'm > > wondering what other approaches others have taken. > > > > Thanks, > > > > Eric > > > > ________________________________________________________________________ > > TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > > with unsubscribe witango-talk in the message body > > -- > Mike Tyranski > Lynch2 > p: 847.608.6900 > f: 847.608.9501 > http://www.lynch2.com > ________________________________________________________________________ > TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > with unsubscribe witango-talk in the message body > ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
