I agree with Rick. Client side code to invalidate a session cannot be
relied upon. As an example of what you're asking about, I looked at
one application that used javascript in an attempt to send a logout
request to the server when the user closed the browser window. They
had every link and form on every page first going to a js function
where they set a flag. Then there was an onUnload event on the body
tag that called a js function that checked to see if the flag was set.
If not, they assume the user is closing the browser or navigating
external to the app and they pop a new brower window to submit a
"logout" request. Unfortunately for them, the whole scheme was foiled
when browsers introduced the popup blocker.
Dave
On 9/15/06, Rick Zhong <sagiko@gmail.com> wrote:
hi,
The basic rule of thumb is that never rely on session control
mechanism at the client side such as using javascript because all the
client side implementations are subject to malicious users' control.
Normally server-side invalidation of session ID after a specific
period of idle time is a recommended practice. The exact length of
this idle time is really subject to the sensitivity and security
requirement of the application.
regards,
Rick Zhong
On 9/15/06, Matteo Nava <ilnava@gmail.com> wrote:
> Hi,
>
> Normally in web application, when a user end his session, not logging
> out, but simply closing the browser, the session token stay valid
> until the session timed out, and so it's potentially reusable.
>
> In my opinion it's recommendable that some kind of a mechanism is
> implemented for invalidate the session token when user close the
> browser, for example, with a client side javascript code using the
> onunload event to invalidate the session token. But I haven't found a
> best practices or any other discussion about this problem.
>
> Best Regards,
>
> Matteo Nava
>
> -------------------------------------------------------------------------
> Sponsored by: Watchfire
>
> Securing a web application goes far beyond testing the application using
> manual processes, or by using automated systems and tools. Watchfire's
> "Web Application Security: Automated Scanning or Manual Penetration
> Testing?" whitepaper examines a few vulnerability detection methods -
> specifically comparing and contrasting manual penetration testing with
> automated scanning tools. Download it today!
>
> https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008Vmm
> --------------------------------------------------------------------------
>
>
-------------------------------------------------------------------------
Sponsored by: Watchfire
Securing a web application goes far beyond testing the application using
manual processes, or by using automated systems and tools. Watchfire's
"Web Application Security: Automated Scanning or Manual Penetration
Testing?" whitepaper examines a few vulnerability detection methods -
specifically comparing and contrasting manual penetration testing with
automated scanning tools. Download it today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008Vmm
--------------------------------------------------------------------------
-------------------------------------------------------------------------
Sponsored by: Watchfire
Cross-Site Scripting (XSS) is one of the most common application-level
attacks that hackers use to sneak into web applications today. This
whitepaper will discuss how traditional CSS attacks are performed, how to
secure your site against these attacks and check if your site is protected.
Cross-Site Scripting Explained - Download this whitepaper today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008Vmr
--------------------------------------------------------------------------
