Case 1: spidered session has expired. Someone hits the link with the expired
userref and has cookies off. I believe they just revived that session -
started another with the same id.

Case 2: (real) Person on a witango site that uses userrefarg. Copies link
and posts it to a group. Everyone in that group now has direct access to a
live session. That session stays live as long as someone in the group it
hitting it within the timeout period. Sort of a flashmob session.


On 10/13/04 10:17 AM, "Stefan Gonick" <[EMAIL PROTECTED]> wrote:

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


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

Reply via email to