On Thu, 9 Jan 2003, Shrotriya, Sumit wrote:
> Date: Thu, 9 Jan 2003 12:45:20 -0600 > From: "Shrotriya, Sumit" <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: 'Tomcat Users List' <[EMAIL PROTECTED]> > Subject: RE: HTTPS to HTTP > > Craig, > > I agree with you 100% but there can be a simple solution to the problem > that you just raised..and that is that a new session id is created and > mapped in some table when moving from https-->http this way user B can not > get access to the admin page. > How would this stop B? After the switch back to HTTP, if a session id works for A it will also work for B. It doesn't matter whether it's a "real" session id or a "mapped" session id -- the problem is that B can snoop it in cleartext. > ~Sumit Craig > > > On Thu, 9 Jan 2003, John Holman wrote: > > > Date: Thu, 09 Jan 2003 12:56:16 +0000 > > From: John Holman <[EMAIL PROTECTED]> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > > To: Tomcat Users List <[EMAIL PROTECTED]> > > Subject: Re: HTTPS to HTTP > > > > Yes, that is clearly a risk. The *whole* web application needs have no > > risks in order to allow http access to any of it - any sensitive link > > and it must all be https. (And of course if SSO is enabled *all* web > > applications for the virtual host must be considered safe). > > Otherwise I'm not convinced that session stealing is really a problem - > > though open to counter-arguements. > > > > Consider a scenario where you have "admin" pages that require SSL, and > normal pages that can run on either. Assume Tomcat were modified to > migrate your session back. > > Consider the following course of events: > > * User A logs on, selects link for an admin function, > and is switched to SSL for that part. > > * User A then switches back to non-SSL. Among other things, > this means that the session id is now visible in plaintext > on the wire. > > * User B snoops the network, acquires the session id, > and submits an SSL request (with the stolen session id) > to an admin function. > > * Server blithely executes the forged request, because login > identity is attached to the session id (which is now > plaintext -- it wouldn't be if the session had been > created under SSL and never allowed to switch back). > > Once an application has switched from HTTP to HTTPS for a session, it > should be programmed to never go back again. > > > John > > > > Craig > > > > Ralph Einfeldt wrote: > > > > >But be aware that quite simple changes in the > > >configuration of tomcat can lead to big security holes. > > >Guess what happens if you or somebody else someday > > >decides to switch from basic authentification to form > > >authentifcation and the sysadmin visits the user side > > >and somebody steals the sysadmins session ...) > > > > > > > > > > > >>-----Original Message----- > > >>From: David Hemingway [mailto:[EMAIL PROTECTED]] > > >>Sent: Thursday, January 09, 2003 12:08 PM > > >>To: Tomcat Users List > > >>Subject: Re: HTTPS to HTTP > > >> > > >>Thats is my exact situation. The sysadmin section of teh site > > >>is 100% https. > > >>but the on the user side there is nothing that sensitive and > > >>little harm they could be cause stealing someones session. > > >>It would not be worth going to the trouble of stealing the > > >>session for the benefit you would get. > > >> > > >> > > >> > > > > > >-- > > >To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > >For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
