tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George Sexton" <>
Subject RE: Session Expires At Every Request (Tomcat5.0.28/Firefox)
Date Wed, 15 Feb 2006 21:08:59 GMT

> -----Original Message-----
> From: Filip Hanik - Dev Lists [] 
> 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.
Voice: 303 438 9585

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message