Re: Fwd: Security Paper: Session Fixation Vulnerability in Web-based Applications

[Craig_Sullivan () Waitrose co uk]

|   The whole thing reminds me of something a friend pointed me to a
|   couple of weeks ago: Using the same session id on both unencrypted and
|   encrypted communication.  Many web sites let you start with plain
|   HTTP, and switch to HTTPS as soon as you want to log in.  If someone
|   sniffs the victim's session ID before the victim logs in over HTTPS,
|   that someone may, in many cases, use that very same session ID to
|   impersonate the victim after he has been authenticated.  The solution
|   is, as with session fixation, to invalidate the session (and create a
|   new one) when switching from unauthenticated to authenticated user.

Yes,

I've built several session tracking models for e-commerce sites that
utilise two session IDs - one held for the duration of the complete session
in a permanent cookie.  The second session ID is only set up and checked
during SSL operations (e.g. logging in, checking out) and is a transient
(temporary) secure cookie.

We also use timestamps to handle session inactivity timeouts.  The way the
system is built is on the following premise - "Only the browser instance
that originally collected successful user authentication information will
be able to do anything with that customers session".  The only way around
this would be for someone to get access to the session ID from the
transient cookie in memory from the browser instance that took the customer
login.

Just one other important point here (and this is why many commercial
systems use the same session ID for http/https) - if you want to manage
state in a way that allows later log analysis, you have to have something
that knits together actitivity from one user across http and https
sessions.  Having different session IDs would cause problems in knitting
together activity so to get around this, there is a generic background
session ID and a secure one tied to authentication details in the back end
Db.  This allows the generic session ID to be used for visitor tracking and
the secure ID for checking validity of sessions attempting to access
sensitive data.

I can't think of any way of preventing capture of the session ID from the
browser memory space but just for completeness, I never echo back or
provide access to sensitive data (even customers can't see their credit
card details for example).

Craig.






*********************************************************************

Notice:  This email is confidential and may contain
copyright material of the John Lewis Partnership.
If you are not the intended recipient, please
notify us immediately and delete all copies of this
message.  (Please note that it is your responsibility
to scan this message for viruses).


*********************************************************************

John Lewis plc                  Registered in England 233462
Registered office               171 Victoria Street London SW1E 5NN
      
Websites: http://www.johnlewis.com and http://www.waitrose.com