Re: best practices

["Dave Ferguson" <gmdavef () gmail com>]

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
--------------------------------------------------------------------------