mailing list archives
RE: improvements in session management?
From: "WebAppSecurity [Technicalinfo.net]" <webappsec () technicalinfo net>
Date: Thu, 1 Apr 2004 22:46:19 +0100
But after rethinking maybe the original poster thought about
a second login with a *valid* authentication. This would not
be vulnerable to DoS attack.
That is correct - it has to do with simultaneous 'live' logins/sessions.
Well, still I'd assume it's bad advice to close all sessions.
A better approach would be to refuse the second login.
It is a question of context. There is no quick fix - universal solution.
The session handling mechanism must be tuned the both the applications
nature and the environments you expect users to use the applications from.
The security nuances between retail banking and investment banking online
services are just one instance of subtleties in session handling techniques
and simultaneous logins.
With regards to simultaneous logins - granted, you block another login
attempt. But the issue we are addressing at this stage are multiple
instances of the same login. This may be achieved through <CTRL>-N child
browser instances or through hijacking techniques.
In a nut shell, any session handling routine must be tuned to its unique
1. The sensitivity of the information available through the application.
2. The average technical level of the user (about a third of joe-public has
great trouble with using a mouse and drop-down boxes).
3. The likelihood that the application (or data it contains) would be
4. The physical locations users will access the application from (internet
café - are you going to trust the hosts?).
5. The amount of time it would take to brute-force guess 'unique' session
With regards to web-application authentication - I'd suggest that you review
an earlier paper of mine: