On Fri, 18 Oct 2002, Maninder S Batth wrote:
> Date: Fri, 18 Oct 2002 19:28:59 -0700 > From: Maninder S Batth <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: problem with session tracking and redirection http<---> https > > please correct me if i am wrong. Session id could be hijacked anytime if > it is transmitted as clear text. so once user has loged in , and user > gets new session id , this session id could be sniffed > and the person can still be impersonated.?? Yes. > how is this related to > https-->http transitiion? If the session was originally established on the https connection, the session id has never been transmitted in the clear, so it cannot be hijacked except when the application accepts a non-https request for that session (or the attacker can impersonate an existing SSL session, in which case we've all got much bigger problems). If the session was originally established under https, but the application switches back to http, the session id is transmitted in the clear from that point on, and is subject to hijacking. This is the logical flaw we discussed earlier this week with regards to a request to accept the login screen on https (to avoid the password being transmitted in the clear) and then switch back to http for the remainder of the session. From the security point of view, this is worse than useless (worse because it gives you a false sense of confidence). Craig > > Craig R. McClanahan wrote: > > >On Fri, 18 Oct 2002, Henrik Bentel wrote: > > > > > > > >>Date: Fri, 18 Oct 2002 23:07:17 +0000 > >>From: Henrik Bentel <[EMAIL PROTECTED]> > >>Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > >>To: [EMAIL PROTECTED] > >>Subject: Re: problem with session tracking and redirection http<---> https > >> > >> > >> > >>yeah, I always encode the redirection URL. > >>it's waird that it works if the session is created which under http, but not > >>under https. > >> > >>bug maybe? > >> > >> > >> > > > >Nope ... avoidance of a huge security hole. > > > >Once a session is accessed via https, it should never ever be allowed to > >be accessed from http again. The reason for this is that the session id > >is transmitted in clear text, so anyone who can snoop the network can > >hijack your session and impersonate the originally authenticated user > >(even if that user originally authenticated on an encrypted channel). > > > >Do not, under any circumstances, design applications that depend on > >maintaining session state across an https --> http transition. > > > >Craig McClanahan > > > > > >-- > >To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> > >For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org> > > > > > > > > -- > Your favorite stores, helpful shopping tools and great gift ideas. > Experience the convenience of buying online with Shop@Netscape! > http://shopnow.netscape.com/ > > -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
