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