Hijacking is possible for any "man-in-the-middle" situation. That's one of the reasons that going https for just the login is a bad idea (tm).
--mikej -=----- mike jackson [EMAIL PROTECTED] > -----Original Message----- > From: Zabel, Ian [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 04, 2003 9:55 AM > To: 'Tomcat Users List' > Subject: RE: Session lost between HTTPS and HTTP > > > Cookies are only valid for a domain though. So if the cookie was > created on > http://banksite.com it will be valid for https://banksite.com as > well. It is > the same website. Banksite.com resolves to the same IP address either way. > It's just a protocol switch. > > You session id will never be sent to a third party server. > > If you go to http://www.bankaffiliate.com and click on a link to > https://banksite.com you will have two different sessions, two different > cookies. Hijacking in that way is not possible. > > Ian. > > -----Original Message----- > From: Filip Hanik [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 04, 2003 12:51 PM > To: Tomcat Users List > Subject: RE: Session lost between HTTPS and HTTP > > This scenario will convince you...maybe :) > > 1. You enter a bank on non secure page- HTTP > 2. You log in and start messing with your accounts > 3. Then you go back to HTTP and somebody can hi-jack your sessionID > 4. They use that ID to go back to HTTPS and now have access to > your account > information. > > For security purposes, I believe Tomcat must use a different > sessionId when > you are in secure mode. Because this ID is encrypted using SSL on HTTPS > mode. > > Filip > > -----Original Message----- > From: Zabel, Ian [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 04, 2003 9:47 AM > To: 'Tomcat Users List' > Subject: RE: Session lost between HTTPS and HTTP > > > As far as I know, http://www.app.com/ and https://www.app.com/ > are supposed > to be allowed to share cookies on standard ports. > > http://w6.metronet.com/~wjm/tomcat/2000/Dec/msg00626.html > > Ian. > > -----Original Message----- > From: Filip Hanik [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 04, 2003 12:40 PM > To: Tomcat Users List > Subject: RE: Session lost between HTTPS and HTTP > > yeah, it is a security issue I believe. Not sure how tomcat does that, but > it shouldn't allow a session that was created on HTTPS to switch to HTTP. > > Filip > > -----Original Message----- > From: Zabel, Ian [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 04, 2003 9:35 AM > To: [EMAIL PROTECTED] > Subject: Session lost between HTTPS and HTTP > > > All; > > > > We are having a chronic problem that is causing a lot of trouble with our > application's users. > > > > In our app, we authenticate users on our HTTPS server and then serve the > homepage also on HTTPS. All links on the homepage to the other > pages in our > app switch the user to the same url on HTTP. If a user's session > is created > on HTTPS (https://www.app.com <https://www.app.com/> ), when they are > switched over to HTTP (http://www.app.com <http://www.app.com/> ) the > session cookie is not sent by the browser and they therefore lose their > session. > > > > NOTE: This is not a problem if the user's session is created on HTTP. The > session is created on HTTP, they authenticate over HTTPS and then are > switched back to HTTP, and their session is maintained with no problems. > > > > Our workaround has been to pass the jsessionid on the url wherever we can, > but there are places we can't do this. > > > > We did not start having this problem until we switched from > Apache/ServletExec to Apache/Tomcat4.0.x/mod_jk. > > > > We are using Apache with OpenSSL to serve our HTTPS pages. > > > > Is it valid for a cookie created on HTTPS to be sent to the same exact URL > on HTTP? > > > > Ian. > > > > > > > --------------------------------------------------------------------- > 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]
