WebApp Sec: Re: improvements in session management?

[Tim Akinbo <takinbo () yahoo com>]

There's likely to be usability problems with this approach. Consider a 
situation where a user would be accessing your application from 
anonymous proxies? Certain anonymous proxies modify the headers in HTTP 
requests and could also modify the USER-AGENT which could spell trouble 
for your application. There's always a trade-off between security and 
usabilitiy. You would have to choose one.
Regards,
Tim
http://timba.cowblock.net/

PS: This is my first post on this list :)

Mark Foster wrote:

> 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.