RE: improvements in session management?

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

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.

I assume that your reference to ID1 cookie is in fact a unique,
non-guessable value - and is to all intents and purposes the sessionID for
the users connection?  In which case you don't appear to be doing anything
different from the majority of custom session management solutions - perhaps
just reinventing the wheel if the web service  you are using (IIS, Apache
etc.) already supports a solid session management structure that you could
use/reference from your custom application instead.

It is of course to make quite sure that any sessionID allocated during a
non-authenticated connection over HTTP - is not the same one after a user
has been server-side redirected to the HTTPS site onece they have
successfully authenticated.

Ou make mention of "ties them to the browser they logged in with" - why
should this matter?  In most cases the same user, on the same machine, will
use the same web browser (maybe a different instance)... And any corporate
user will find that they probably have identical configurations as everyone
else on their network... So the only uniqueness your application would be
able to observer is the unique value you initially assign them when they
first access the application.

The purpose of path checking routines is dependant upon the type of
application being developed and whether you intent to allow users to have
multiple browser connections open to the same application process -- as well
as working to "break" almost all current automated (in)security tools.

Cheers,

Gunter


> -----Original Message-----
> From: Mark Foster [mailto:mark () foster cc] 
> Sent: 31 March 2004 21:29
> To: webappsec () securityfocus com
> Subject: Re: improvements in session management?
>
> WebAppSecurity [Technicalinfo.net] wrote:
> > For a full explaination etc. see the section "Good Session 
> Management" 
> > on 
> http://www.technicalinfo.net/papers/WebBasedSessionManagement.html
> > ... As well as further analysis on what constitutes 
> good/bad practices.
>
> Ok, I've read this paper and have an idea about how to do 
> session mgmt. 
> I am planning on doing session tracking within a cgi-based 
> apache webapp & using cookies as follows...
> 1. New & returning users get a unique cookie (ID1) 2. If 
> necessary, they login through an HTTPS-protected html form 
> using pre-existing credentials (username & password) 3. Upon 
> logging in, the server stores the following in the database 
> session table:
>       ID1 - the cookie they got
>       username - who they logged in as
>       expires - date/time that the session expires, +20 min default
>       user_agent - the browser's identifier in 
> $ENV{HTTP_USER_AGENT} Then, whenever the client accesses any 
> dynamic (CGI) pages, the session expiration value can be 
> re-extended for another 20 minutes.
>
> I believe this scheme works because the client does not know 
> the session-id and in fact there is no session id, only 
> requires one cookie, the value of which can be public 
> knowledge. It also ties them to the browser they logged in with.
> The problems are a) need a process to reap the expired 
> sessions - not a big deal; and b) someone could hijack the 
> session by spoofing the user_agent and ID1 cookie if they 
> were quick enough and knew the scheme. 
> Maybe this could be circumvented by looking at REMOTE_ADDR, 
> but I think this value is not too reliable especially with 
> proxies and such. It also doesn't have the path-checking 
> integrity feature described in your paper.
> Can you or anyone shoot some holes in this? I want to do this right.
> --
> Some days it's just not worth chewing through the restraints...
> Mark D. Foster, CISSP <mark () foster cc>  http://mark.foster.cc/