Home page logo
/

webappsec logo WebApp Sec mailing list archives

Re: improvements in session management?
From: Tim Akinbo <takinbo () yahoo com>
Date: Thu, 01 Apr 2004 23:14:01 +0100

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.



  By Date           By Thread  

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