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
> > > >
> > > >
> > _______________________________________________________________________
> > > > _
> > > > 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
> >
> > _______________________________________________________________________
> > _
> > 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

________________________________________________________________________
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


________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

Reply via email to