|
List Info
Thread: best practices
|
|
| best practices |

|
2006-09-15 02:31:21 |
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/whi
tepapers.aspx?id=701500000008Vmm
------------------------------------------------------------
--------------
|
|
| best practices |

|
2006-09-15 08:31:10 |
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/whi
tepapers.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/whi
tepapers.aspx?id=701500000008Vmm
------------------------------------------------------------
--------------
|
|
| best practices |

|
2006-09-15 08:31:10 |
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/whi
tepapers.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/whi
tepapers.aspx?id=701500000008Vmm
------------------------------------------------------------
--------------
|
|
| best practices |

|
2006-09-15 08:31:10 |
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/whi
tepapers.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/whi
tepapers.aspx?id=701500000008Vmm
------------------------------------------------------------
--------------
|
|
| best practices |

|
2006-09-18 15:34:00 |
Yo!
Rick Zhong 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.
Rule of a thumb it may be, but it does not apply in this
case. In most
cases a user with a valid session can always end the session
(logout). A
client-side javascript to do that (logout) will only enhance
the
security for the good users (their possibly abusable
sessions won't be
left hanging) but will give nothing new to work with for the
said
malicious users.
Possible issues involved may include multiple windows using
one session
where closing one window will end the session in the other
window as
well (if your application makes sense in multiple windows
and is used in
a setup like that).
Siim Põder
------------------------------------------------------------
-------------
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/whi
tepapers.aspx?id=701500000008Vmr
------------------------------------------------------------
--------------
|
|
| best practices |

|
2006-09-15 15:21:21 |
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/whi
tepapers.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/whi
tepapers.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/whi
tepapers.aspx?id=701500000008Vmr
------------------------------------------------------------
--------------
|
|
[1-6]
|
|