Re: improvements in session management?

[Michael Ströder <michael () stroeder com>]

WebAppSecurity [Technicalinfo.net] wrote:
> I don't see the necessity for storing the user_agent for session handling -
> unless you need it to decide on which client-side code components you will
> introduce as part of a dynamic application.  Like any field submitted in
> HTTP(S) headers, it can be defined by the client and overwritten as
> necessary - so HTTP_USER_AGENT is most certainly not a unique field that can
> be trusted.

HTTP_USER_AGENT is most certainly not a field that can be trusted - but it 
raises the bar. So do other HTTP headers...

In PyWebLib (see http://www.stroeder.com/pylib/PyWebLib/) I'm storing all 
environment vars available at the first HTTP request which you can assume to 
be constant within one browser session into the session object. The session 
object is always referenced by a random session ID and for each hit there's 
a cross-check done. Most times I pass the session ID in the URL (in PATH_INFO).

Candidates for cross-checking env vars are (constant list from the Python 
source):

SESSION_CROSSCHECKVARS = (
  """
  List of environment variables assumed to be constant throughout
  web sessions with the same ID if existent.
  These env vars are cross-checked each time when restoring an
  web session to reduce the risk of session-hijacking.

  Note: REMOTE_ADDR and REMOTE_HOST might not be constant if the client
  access comes through a network of web proxy siblings.
  """
  # REMOTE_ADDR and REMOTE_HOST might not be constant if the client
  # access comes through a network of web proxy siblings.
  'REMOTE_ADDR','REMOTE_HOST',
  'REMOTE_IDENT','REMOTE_USER',
  # If the proxy sets them but can be easily spoofed
  'FORWARDED_FOR','HTTP_X_FORWARDED_FOR',
  # These two are not really secure
  'HTTP_USER_AGENT','HTTP_ACCEPT_CHARSET',
  # SSL session ID if running on SSL server capable
  # of reusing SSL sessions
  'SSL_SESSION_ID',
  # env vars of client certs used for SSL strong authentication
  'SSL_CLIENT_V_START','SSL_CLIENT_V_END',
  'SSL_CLIENT_I_DN','SSL_CLIENT_IDN',
  'SSL_CLIENT_S_DN','SSL_CLIENT_SDN',
  'SSL_CLIENT_M_SERIAL','SSL_CLIENT_CERT_SERIAL',
)

I think the comments are clear enough.

As you might guess when running with SSL you gain really secure session 
cross-checking by looking at SSL_SESSION_ID since you can rely on the SSL 
session managment of e.g. Apache/mod_ssl. In case you have client certs you 
can use that env vars to raise the bar even more.

This approach works from the very same source. It just uses automagically 
everything what's there for cross-checking when the web session is created. 
Likely this is not the right approach if you want to track sessions in the 
long run for statistical purposes.

Off course you can extend the list when creating the session handler 
instance to suit your proprietary needs.

Ciao, Michael.