Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43F39BDE.3050509@hanik.com>
Date: Wed, 15 Feb 2006 15:23:42 -0600
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Session Expires At Every Request (Tomcat5.0.28/Firefox)
References: <20060215211602.392111C3BA@mail.mhsoftware.com>
In-Reply-To: <20060215211602.392111C3BA@mail.mhsoftware.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Adam and Mallory have to stop shopping! =)

this debate has been going on for years, you just caught onto to it now, 
and I was in it last time, don't plan on participating again. Have fun 
with it though!!

Filip


George Sexton wrote:
> An even simpler case:
>
> Adam visits a banking site. On entering the site he gets a cookie. 
>
>
> Mallory snoops the session ID on the data stream.
>
> Adam then authenticates to read his account information. The application
> sets a session attribute (say a bean with the account name and number) on
> the session.
>
>
> Mallory now enters the secure area of the banking site using the forged
> session ID. 
>
> Poof. Mallory is logged in as Adam.
>
> Poof. Adam is had and his data is there to be stolen, or wire transferred to
> another account.
>
>
>
> George Sexton
> MH Software, Inc.
> http://www.mhsoftware.com/
> Voice: 303 438 9585
>   
>
>   
>> -----Original Message-----
>> From: George Sexton [mailto:gsexton@mhsoftware.com] 
>> Sent: Wednesday, February 15, 2006 2:09 PM
>> To: 'Tomcat Users List'
>> Subject: RE: Session Expires At Every Request (Tomcat5.0.28/Firefox)
>>
>>
>>
>>     
>>> -----Original Message-----
>>> From: Filip Hanik - Dev Lists [mailto:devlists@hanik.com] 
>>> Sent: Wednesday, February 15, 2006 1:16 PM
>>> To: Tomcat Users List
>>> Subject: Re: Session Expires At Every Request (Tomcat5.0.28/Firefox)
>>>
>>> George Sexton wrote:
>>>       
>>>> Does the code transparently create a new JSessionID value then?
>>>>         
>>> George,
>>> you might wanna rethink your comments, they don't shine any 
>>> light on the 
>>> issue and they for sure don't state any facts, let me prove 
>>>       
>> you I am 
>>     
>>> right. Below is the headers I tracked with LiveHttpHeaders, 
>>> as you can 
>>> see, JSESSIONID remains exactly the same in the browser 
>>> request when the 
>>> switch from HTTP to HTTPS happens.
>>>       
>> And this is an incredibly major trap that lies waiting for 
>> every application
>> developer that uses sessions. You see, I have given a great 
>> deal of thought
>> about sessions and what should happen when a connection transitions to
>> secure, or from secure to non-secure.
>>
>> Let's take a simple shopping cart app. User Adam visit a site on a
>> non-secure connection and receives a session. He shops and 
>> puts something in
>> his cart.
>>
>> Mallory (crypto speak for the person in the middle) monitors 
>> Adam's network
>> stream and picks up the jsessionid from the data stream.
>>
>> Adam then goes to the check out screen and starts entering 
>> checkout data
>> (name, address, and credit card information). To give 
>> ourselves a window,
>> assume that Adam then continues shopping or is just slow, or 
>> the credit card
>> processing procedure takes time...
>>
>> Mallory can forge a request using the JSessionID, and go to 
>> the checkout
>> pages. Since Mallory has the same session, all of the 
>> information entered by
>> Adam is now visible.
>>
>> This is the flaw. This is why sessions should not transition 
>> from non-secure
>> to secure, or if they do transition a new ID should be 
>> generated and the old
>> session ID invalidated. The session ID is a key into the data 
>> store and if
>> the session key has been exposed to the public, then no 
>> confidential data
>> should be accessed using that session key.
>>
>> I think this should be submitted as a bug. 
>>
>>
>> George Sexton
>> MH Software, Inc.
>> http://www.mhsoftware.com/
>> Voice: 303 438 9585
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>     
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org