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]

Reply via email to