that a userref has expired and just reuses it. To me, that is where the problem
lies. If session cookies are disabled, the server should still be able to determine
that UserRefA was an old expired one and assign a brand new one. This would
make all of the scenarios secure and usable without having to jump through
programming hoops nor stop using @userreferenceargument.
With Enterprise: What do you say?
Stefan
At 04:11 PM 10/13/2004, you wrote:
Let me suggest that you tail the log so you can see the UserReference that the server assigns or uses as you test out the scenarios.
A -- session cookies enabled at useragent 1. No session cookie presented by UserAgent, no UserReference in the URL 2. No session cookie presented by UserAgent, UserReferenceA in the URL 3. No session cookie presented by UserAgent, UserReferencB in the URL 4. Session cookie presented by UserAgent, no UserReference in the URL 5. Session cookie presented by UserAgent, UserReferenceA in the URL 6. Session cookie presented by UserAgent, UserReferenceB in the URL
B -- session cookies disabled at useragent Now turn of cookies, and run tests 1, 2, 3.
First with cookies enabled (the approach advocated by Scott et al.), you'll see that a) if a cookie doesn't exist, one will be assigned, and it will override the UserReference in the URL -- no session hijacking. b) if a session cookie does exist, it will be used, again no session hijacking
Now turn the cookies off. B1 will show that every request generates a new user reference B2 and B3 will show that the userreference presented by the useragent in the search arguments (url) is used.
Now open up a different browser (say you've been using IE, so open up firefox). Now copy case B2 into the new browser window. You've just hijacked the sesssion of the IE user.
Clear?
On Wednesday, October 13, 2004, at 12:56 PM, Stefan Gonick wrote:
It seems to me then that the system would be more secure if the Witango server always assigns a new userref when encountering an old expired one when cookies are off rather than reusing the old one. Does this make sense to anyone?
It would be great if With joins in at some point and explains how the server actually is designed to work in these scenarios.
Stefan
At 03:45 PM 10/13/2004, you wrote:
On 10/13/04 12:29 PM, "Stefan Gonick" <[EMAIL PROTECTED]> wrote:
Let's see if I have this right.
UserA comes in through Google with UserRefA, which is old. The Witango server determines that UserRefA has expired and assigns UserRefB to UserA. Is this correct?
Not necessarily. There are cases where the new visitor gets UserRefA, the old expired one. A new session is created with an old ID. I�ve found this to be true in the case of visitors with cookies off.
If so, UserA continues using the site and now has UserRefB propagating across all pages through the <@userreferenceargument>.
UserD now comes in 5 minutes later with UserRefA. Is it true that the server, at this point in time, views UserD as the same person as UserA, even though none of UserA's links have UserRefA in them anymore? UserA now has UserRefB. The server, therefore, allows UserD to join in UserA's session and gives UserD the same UserRefB?
Is this how it works? This seems to be what you are saying. I find that hard to believe if so. Alternatively, I may be wrong on the first question where I assumed that the server would assign a new userref when it has determined that the old one had expired. Please enlighten me.
Thanks, Stefan
At 02:38 PM 10/13/2004, you wrote: Thank you again Ian,
In addition - anybody remember that statement "the web is stateless"?
It's all about whether or not the Witango server (or any web platform) can tell the difference between two different people over the Internet - it can't.
As far as Witango (or any web platform) is concerned, because of the session ID in the Search Engine link - the two users are the same person, thus the shared session.
Removing session information from a URL argument string (<@USERREFERENCEARGUMENT>) is your first best step in tackling the problem - then relying on session-cookies to uniquely identifying you over the Internet (provide "state") is the next best step.
The Internet is not perfect and can never be 100% secure - so you have to strive to provide the best possible solution and security at all times.
Session-cookies are also not perfect - but they are the best option you have.
To understand web programming, you have to understand "state".
Does anybody not know what I mean by "state" in context of the web?
-----Original Message----- From: "Ian Daniel" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Date: Wed, 13 Oct 2004 11:10:41 -0700 Subject: RE: Witango-Talk: Cookies
> Ahh .. > > When your User1 came, supplied a UserReferenceArgument ("URA"), the > server, > if Witango 5, checked for a UserReferenceCookie ("URC"). Finding none, > it > assumed the value of the expired URA, seeing no reason why it should be > rejected. > > Note: I have not tested the above scenario with the very latest > versions of > Witango. I am making a rather bold assumption that the above scenario > .. > which was true ... is still true. I haven't seen anything which leads > me to > believe otherwise. > > User 2 came along with the same URA, and having no URC, the server > obliged > and allowed the second browser to share the now current variable store > created by User1. > > Does this help? The "error" may be in thinking that the server would > not > "honor" the expired URA by establishing a session with the value of > that > argument. > > tks, > Ian > > > -----Original Message----- > From: Stefan Gonick [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 13, 2004 10:37 AM > To: [EMAIL PROTECTED] > Subject: RE: Witango-Talk: Cookies > > > Hi Ian, > > Thanks for joining in. Let's re-examine your scenario: > > User 1 clicks on the link and the Witango server detects > that the session was expired and starts a new session assigning > userreference A. > > A moment later User 2 clicks on the link and the Witango server detects > that the session was expired and starts a new session assigning > userreference B. > > It seems to me that the server would assign two different userrefs > to those users rather than them sharing one. I doubt that > it stores some connection between the old expired userref and > the newly generated one. The rest of your scenario would not > exist if I'm right. > > So, how does this really work? > > Stefan > > At 01:26 PM 10/13/2004, you wrote: > >Ok .. take a break, Scott ... I'll try this on .... > > > >Stefan .. you are correct in what you have said, but consider this: > > > >If two independent users then find that spidered, expired session ... > and > >each independently come to the site, using the same > UserReferenceArgument > >from the spidered, expired session, and each begin a shopping cart > >experience, can you imagine the result? > > > >Let's see .. I'll place some items in the basket .. you do too. We > both > >head to the checkout .. I put the shipping address, just in the nick > of > time > >overwriting yours which you just posted, but I then go looking for my > credit > >card while you complete the order. We then use your credit card to > ship an > >order to me. > > > >Are we having fun yet? > > > >o[;-) > > > >-----Original Message----- > >From: Stefan Gonick [mailto:[EMAIL PROTECTED] > >Sent: Wednesday, October 13, 2004 10:17 AM > >To: [EMAIL PROTECTED] > >Subject: Re: Witango-Talk: Cookies > > > > > >Hi Scott, > > > >Forgive me if I find this explanation less than satisfying. :) > >If sessions typically expire after 30 minutes of inactivity, > >then spidered sessions would extremely likely have expired > >by the time someone has clicked on the link. Am I missing > >something here? > > > >Stefan > > > >At 01:10 PM 10/13/2004, you wrote: > > >Hi Stefan, > > > > > >Who knows if it ever expired? > > > > > >Personally, I think the bug is using <@USERREFERENCEARGUMENT> > period. > > > > > >Just remove it - and more than one problem is solved. > > > > > > > > >-----Original Message----- > > >From: Stefan Gonick <[EMAIL PROTECTED]> > > >To: [EMAIL PROTECTED] > > >Date: Wed, 13 Oct 2004 12:58:56 -0400 > > >Subject: Re: Witango-Talk: Cookies > > > > > > > What kind of factor can lead to the resurrection of an expired > session? > > > > > > > > Stefan > > > > > > > > At 01:04 PM 10/13/2004, you wrote: > > > > >Hi Stefan, > > > > > > > > > > > I STILL don't understand why UserReferences from a week ago > should > > > > > > lead to session hijacking. Wouldn't this UserReference have > expired > > > > a > > > > > > long > > > > > > time ago? Wouldn't that result in creating a new > UserReference? If > > > > not, > > > > > > wouldn't this be considered a bug? > > > > > > > > > >There can be more than one factor involved with why this can > happen, > > > > and > > > > >therefore hard to > > > > >eliminate. > > > > > > > > > >Keep in mind this problem plagues more web development platforms > than > > > > just > > > > >Witango. > > > > > > > > > >This is more of a flaw in the Internet "architecture" brought > about > by > > > > the > > > > >addition of > > > > >user "convenience" - but that convenience is superseded now by > > > > security > > > > >concerns. > > > > > > > > > >Basically, in my opinion - just don't use > <@USERREFERENCEARGUMENT> > for > > > > any > > > > >reason. > > > > > > > > > >Hope this helpful. Cheers.... > > > > > > > > > > > Stefan > > > > > > > > > > > > ===================================================== > > > > > > Database WebWorks: Dynamic web sites through database > integration > > > > > > http://www.DatabaseWebWorks.com <http://www.databasewebworks.com/> > > > > > > > > > > > > > > > > > _______________________________________________________________________ > > > > > > _ > > > > > > TO UNSUBSCRIBE: Go to > http://www.witango.com/developer/maillist.taf > > > > > > > > > > > > > > > >______________________________________________________________________ > > > > __ > > > > >TO UNSUBSCRIBE: Go to > http://www.witango.com/developer/maillist.taf > > > > > > > > ===================================================== > > > > Database WebWorks: Dynamic web sites through database integration > > > > http://www.DatabaseWebWorks.com <http://www.databasewebworks.com/> > > > > > > > > > _______________________________________________________________________ > > > > _ > > > > TO UNSUBSCRIBE: Go to > http://www.witango.com/developer/maillist.taf > > > > > > > > > >______________________________________________________________________ > __ > > >TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > > >===================================================== > >Database WebWorks: Dynamic web sites through database integration > >http://www.DatabaseWebWorks.com <http://www.databasewebworks.com/> > > > >______________________________________________________________________ > __ > >TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > > >______________________________________________________________________ > __ > >TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > ===================================================== > Database WebWorks: Dynamic web sites through database integration > http://www.DatabaseWebWorks.com <http://www.databasewebworks.com/> > > _______________________________________________________________________ > _ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > _______________________________________________________________________ > _ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
_______________________________________________________________________ _ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
===================================================== Database WebWorks: Dynamic web sites through database integration http://www.DatabaseWebWorks.com <http://www.databasewebworks.com/>
_______________________________________________________________________ _ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
----------------------------------------- Roland Dumas Roberts Information Services 310 W. Bellevue Avenue San Mateo CA 94402 650-347-1373 415-412-9300 (cell) [EMAIL PROTECTED] SMS: http://new.servqual.com/html/sms.tml
_______________________________________________________________________ _ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
===================================================== Database WebWorks: Dynamic web sites through database integration http://www.DatabaseWebWorks.com________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
=====================================================
Database WebWorks: Dynamic web sites through database integration
http://www.DatabaseWebWorks.com
________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
