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_at_rodsdot.com]
> Sent: Tuesday, May 02, 2006 8:40 AM
> To: test.future_at_gmail.com
> Cc: webappsec_at_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_at_gmail.com [mailto:test.future_at_gmail.com]
> Sent: Tuesday, May 02, 2006 2:41 AM
> To: webappsec_at_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
--------------------------------------------------------------------------
Received on May 03 2006
Intro
