Oddly enough, the banks don't even care about this. US Bank, for example, claims their login on the front page is "secure" and has you enter your account data into a non https form. After the browser sends the information, it then redirects to a secure(https) link.
I wrote them about this, and their response was, we know it's not secure, but we'll compensate you for any losses you may have... Crazy. -----Original Message----- From: George Sexton [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 15, 2006 3:16 PM To: 'Tomcat Users List' Subject: RE: Session Expires At Every Request (Tomcat5.0.28/Firefox) 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]
