RE: improvements in session management?

["WebAppSecurity [Technicalinfo.net]" <webappsec () technicalinfo net>]

> While including additional information is nice, be careful 
> that you don't also pick information that may not stay the 
> same during a valid session.  For instance, REMOTE_ADDR can 
> change due to a load balanced proxy setup.

That is most certainly correct - and specially the case with AOL users etc.

While it most certainly possible to log/reference everyfield that comes back
from the browser, there is only a certain about of "randomness" within these
headers to "guarantee" some kind of uniquness.  As IE is the most popular
browser, there are probably only a hundred reasonably common permutations on
the HTTP_USER_AGENT field... Not particularly random or unique.  By simply
increasing the byte length of the unique sessionID at the client end will
increase this randomness.  I don't really believe that by taking in all
these "unique" browser fields you will achieve as much as simply increasing
the sessionID value length by another 50 or 100 characters.  So why make
life more complex?

It is vital that the application developer understand their user base.  Just
who is going to be using the application?  If you expect anyone to use the
application on the internet - where are the most likely places that someone
could take over an active session?

It doesn’t take too much work to figure that the most success for hijacking
e-banking sessions for instance is to go to an Internet Café and do it from
there.  All the hosts will be configured the same, NATed to the same IP
address, using the same infrastructure... on the same LAN etc.  In addition,
the threat of observing someones session information is very much higher.

The threat of observing session information is always a potential backdoor
to these types of secure applications.  How do you protect against this???
Not very easily.

The most successful solution I have observered is:  
1.  Only allow any user to have a single active connection to the web
application. (simultaneous logins result in slosure of all sessions).  
2.  Use a strong (long and very random) session ID for uniquness.  
3.  The use of changing session ID's linked to the page/component the user
is accessing.  While the server-side references the REFERER field to ensure
that the user reached the page/component through an approved path.  
4.  Upon accessing the application, through the use of cient-side Java, an
encrypted SOCKS proxy is created that tunnels all interactive traffic
through it (over an HTTPS connection) - but also maintains a secure
heart-beat between client-server.  

Cheers,

Gunter