Home page logo
/

webappsec logo WebApp Sec mailing list archives

Re: improvements in session management?
From: Michael Ströder <michael () stroeder com>
Date: Thu, 01 Apr 2004 02:09:10 +0200

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.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]