[13634] in cryptography@c2.net mail archive
Re: Session Fixation Vulnerability in Web Based Apps
daemon@ATHENA.MIT.EDU (Adam Back)
Sat Jun 14 19:43:09 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Sat, 14 Jun 2003 23:04:12 +0100
From: Adam Back <adam@cypherspace.org>
To: Ben Laurie <ben@algroup.co.uk>
Cc: "James A. Donald" <jamesd@echeque.com>,
cryptography@metzdowd.com, Adam Back <adam@cypherspace.org>
In-Reply-To: <3EEB88CF.2040000@algroup.co.uk>; from ben@algroup.co.uk on Sat, Jun 14, 2003 at 09:42:55PM +0100
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@metzdowd.com
