Session Fixation Vulnerability in Web Based Apps

[Adam Back]

Ben dude wrote:
> The obvious answer is you always switch to a new session after login.
> Nothing cleverer is required, surely?

Well particularly the issue is your login URL should not accept an
existing session identifier supplied by the browser (what the author
of the session fixing paper calls "session adoption").  I would
presume that most people would naturally stomp an existing session
identifier.

Another related issue I'd think would be some login URLs manualy
written or using programing environments may just skip do a redirect
to some application page without prompting the user to login there is
already a still valid session.  In this case the user is logged in as
the attacker, so the attacker doesn't learn the users account info.
Of course it may be that if the user then starts to use the attackers
session, the user may enter something that is private and the attacker
would get that.

Adam

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com