From: Tim Olson <[EMAIL PROTECTED]>
> > > 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
Hmm, I understand, but that mean encrypting every single request (via an SSL connection) to the e-comm site wouldn't it? After a session cookie is set (for any reason), isn't it sent along with every subsequent server request?
Assuming it is, every request (even for product pages and general browsing) has to be encrypted, which doesn't seem practical. That's why I was asking if one could simply reset the session ID after logging in--but without losing the session contents.
> 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
Right, server requests for general browsing shouldn't be encrypted (I don't know any e-comm site that does).
> 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()
But doesn't that discard the session?
_________________________________________________________________
Get McAfee virus scanning and cleaning of incoming attachments. Get Hotmail Extra Storage! http://join.msn.com/?PAGE=features/es
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
