> > > My concern is that > > > since URL encoding > > > exposes the session ID in plain view, it's as good as > > > compromised despite > > > using SSL to encrypt it once the customer logs in. > > > > > > Was that why you were saying to only use session cookies > > > everywhere? > > > >yes > > Ok, I see, but a session cookie is also compromised in a > similar manner > before heading into a protected area where the connection is > encrypted.
that's why you ensure that your first request is over https > Sure, it's not nearly as clearly compromised as with URL > encoding, but it is > still sent in clear text to the server for each request. not with ssl. ssl will encrypt the entire http header including the cookie > Which reminds me...is it possible to make certain URIs only > accessible over > an SSL connection? of course. see your web server docs. >(Or over a certain port? because we'd > know which port is > the SSL port). 443 by default > But I'm guessing this wouldn't really do > anything to help > either because Black Hat could just initiate an SSL > connection to that port > anyway, right? it would get a different session ID > In any case, to solve the problem, is there some way to force > the server > (Tomcat for us) to change the session ID referencing the same > session once > the user logs into a protected area? session.invalidate() --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
