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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
