[17365] in cryptography@c2.net mail archive
Re: What happened with the session fixation bug?
daemon@ATHENA.MIT.EDU (Michael Cordover)
Sun Jun 5 03:24:30 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Sun, 05 Jun 2005 11:59:29 +1000
From: Michael Cordover <mjec@mjec.net>
To: "James A. Donald" <jamesd@echeque.com>
Cc: cryptography@metzdowd.com
In-Reply-To: <42A16F9D.14610.73F7AE6@localhost>
James A. Donald wrote:
| Adversary accesses web site as if about to log in, gets
| a session ID. Then supplies false information to
| someone else's browser, causes that browser on some one
| else's computer to use that session ID. Someone else
| logs in with hacker's session ID, and now the adversary
| is logged in.
An excellent plan and the reason sessions shouldn't be automatically
given to every user of a site. In my experience though, sessions aren't
created until the "login" button is pressed - the malicious user needs
an existing account. This might then become a permissions escalation
problem - emphasis on the might.
Question: how does one convince the victim's browser to use the
malicious ID? And if one can modify cookies on the browser for a remote
site (what needs to be done in most cases), doesn't this raise much more
serious questions about XSS? I think this is probably a low-impact
issue unless sessions are used improperly. Then again, given some web
apps I've seen, might be high impact :/.
Regards,
Michael Cordover
--
http://mine.mjec.net/
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
