maybe you misunderstood me. if I want to pretend that I am you, all I have to do is to put a network packet sniffer between your computer and your bank, look up your session Id and then make a request to your bank server using your sessionId. So I am not switching domain.
Filip -----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]
