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 [EMAIL PROTECTED]