> > As soon as you receive a valid session ID with an invalid key, you
> > invalidate the session and request that the user reauthenticates.
>
> I'm going to disagree with your process here, I don't think you need
> both ID's at the client, I think just the random one should be fine.

The trouble with that is that if you only have the random key, you won't
know which session was busted, and you have done nothing to stop the
actual hijacking. All you have done is created a login box for the
*legitimate* user -- the hijacked session lives on.

In order to *stop* the hijacking, you'll need both a constant session ID
and a random key.

> * One ID will match the current state, if there is no match
> then reauthenticate from scratch (old session should expire).

Trouble here is that you don't know which session to expire when the
second request comes in -- there is no match, so how do you figure out
which session that had this id once upon a time?

> > Note that this doesn't solve the issue with a malicious user
> > taking over a session of a user that has left the site
> > without invalidating the session (using a logout button or the like).
>
> There is nothing that can be done about that - it's analogous to
> putting your ATM card into the machine, getting half way through a
> transaction and then walking off. Timeouts are the only hope.

Unfortunately, this is not so obvious to the user. In the ATM case,
(s)he sticks the card in, punches the code on the keyboard, interacts,
hopefully receiving money and the card back. In the web case, the user
just punches the code; there is nothing keeping the user from walking
away. And the external links as *so* tempting. A javascript ran by the
'onLeave=' method can help, but it only works IE (afaik) and only if the
user has not disabled scripting.

  // J

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]