[17360] in cryptography@c2.net mail archive
Re: What happened with the session fixation bug?
daemon@ATHENA.MIT.EDU (James A. Donald)
Sat Jun 4 12:19:23 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
From: "James A. Donald" <jamesd@echeque.com>
To: cryptography@metzdowd.com, cypherpunks@lne.com
Date: Sat, 04 Jun 2005 09:08:45 -0700
In-reply-to: <42A17570.9070000@algroup.co.uk>
--
James A. Donald wrote:
> > The way to beat session fixation is to issue a
> > privileged and impossible to predict session ID in
> > response to a correct login.
> >
> > If, however, you grant privileges to a session ID on
> > the basis of a successful login, which is in fact
> > the usual practice, you are hosed. The normal
> > programming model creates a session ID, then sets
> > variables and flags associated with that session ID
> > in response to forms submitted by the user. To
> > prevent session fixation, you must create the
> > session ID with unchangeable privileges from the
> > moment of creation.
Ben Laurie wrote:
> How does your attack work?
Your business about MACS and stuff was to prevent the
adversary guessing the users session ID. With "session
fixation", the adversary does not try to guess the
legitimate users session ID, instead he fools the
browser of the legitimate user into using the
adversary's session ID.
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.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
fUQA7VMYJROi7AAUHD8ZmEHReDprBvrg3u3cL2VI
4NzEz9SAfaOzb7GhsAkM//vmMQKDsrdLEInHLumm3
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
