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.
Received on Apr 01 2004
Intro
