What about instances where an identity framework is used, such as CA's
Siteminder or IBM's Identity Mangament Suite? Closing the browser will
result in the session begin invalidated - I'm not sure if that cascades to
releasing other resources or not.
On Wed, 3 May 2006, Auri Rahimzadeh wrote:
In addition, having the session state continues to reserves those resources
on the server. So, if there were open recordsets in memory (bad developer!),
login information, database connections, they all stay there. All closing
the window does (and this assumes you have closed *all* browser windows, not
just the one window that was being used), is tell the browser to destroy the
cookie on the client. This is my no means secure, as has been pointed out by
those questioning "what if the session key is in the querystring", which is
generally frowned upon due to session hijacking attacks and replay attacks.
The performance issue is very real. Imagine a server with 1000 users logging
on in 20 minutes (probably an ASP scenario, and assuming the server is set
up to time out sessions in 20 minutes, which is pretty standard). If each of
them has 100K of session data (developers usually use it for convenience and
for variable/data persistence), that's 100,000K (100 megs), used on the
server. Now 10,000 users? 1 gig... Vertical and horizontal scaling gets
expensive. In addition, the resources you normally need to release per
session aren't released, so you could run out of available database pool
connections, have open hooks on files, and so forth, and basically break
your app. This only gets worse with servers with even longer session
timeouts.
I've never had a client *not* want a logoff button in their site specs,
although they many times forget to ask for one since they're so used to it.
I ask about putting one in and they usually say "of course!"
Keep in mind that users many times may just close their windows instead of
logging out. But many *will* logout, just to be safe/sure.
Ahh, yes, another note: Session variables can be the bain of a developer's
existence, just like cookies. If the wrong data is persisted, and the
developer assumes a session key or cookie doesn't exist, and reads it
without first making sure it's not from an old session or invalid data,
things can get very, very messy (and darn hard to debug).
Thanks again!
Best,
Auri Rahimzadeh
Author
Hacking the PSP
www.hackingpsp.com
-----Original Message-----
From: Rod Divilbiss [mailto:rod@rodsdot.com]
Sent: Tuesday, May 02, 2006 8:40 AM
To: test.future@gmail.com
Cc: webappsec@securityfocus.com
Subject: RE: Is logoff feature necessary
Closing the browser will cause the session to end. It will however takes
some amount of time (usually 20 minutes) for the session to be terminated by
the server. It may be possible for the user to reopen their browser before
the session times out and reestablish the session. (Depends on how session
state is maintained and how the web application is written.)
Having a logoff button which explicitly kills the session is not a bad
thing.
-----Original Message-----
From: test.future@gmail.com [mailto:test.future@gmail.com]
Sent: Tuesday, May 02, 2006 2:41 AM
To: webappsec@securityfocus.com
Subject: Is logoff feature necessary
We have a web applicaiton which do not have logoff button. The developer
claims that it is unnecessary, since the session can be terminated by
closing the browser. Is it correct? Thanks.
-------------------------------------------------------------------------
Sponsored by: Watchfire
The Twelve Most Common Application-level Hack Attacks Hackers continue to
add billions to the cost of doing business online despite security
executives' efforts to prevent malicious attacks. This whitepaper identifies
the most common methods of attacks that we have seen, and outlines a
guideline for developing secure web applications.
Download this whitepaper today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9r
--------------------------------------------------------------------------
-------------------------------------------------------------------------
Sponsored by: Watchfire
The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online
despite security executives' efforts to prevent malicious attacks. This
whitepaper identifies the most common methods of attacks that we have seen,
and outlines a guideline for developing secure web applications.
Download this whitepaper today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9r
--------------------------------------------------------------------------
-------------------------------------------------------------------------
Sponsored by: Watchfire
The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online
despite security executives' efforts to prevent malicious attacks. This
whitepaper identifies the most common methods of attacks that we have seen,
and outlines a guideline for developing secure web applications.
Download this whitepaper today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9r
--------------------------------------------------------------------------
-------------------------------------------------------------------------
Sponsored by: Watchfire
The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online
despite security executives' efforts to prevent malicious attacks. This
whitepaper identifies the most common methods of attacks that we have seen,
and outlines a guideline for developing secure web applications.
Download this whitepaper today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9r
--------------------------------------------------------------------------
