[imp] Fix for broken SQL session handlers since IMP 3.2.2

[Chuck Hagenbuch]

Quoting Michael Schout <mschout at gkg.net>:

> Ok,  setupSessionHandler() is getting called, and it appears to be
> working properly.

Okay.

> My understanding of what getCleanSession() is doing, is that it is
> trying to throw out the old session id, and generate a new session id.
> In other words, after login, the old session data should get removed,
> and a NEW session id should get used (and the new session data should go
> there).  Is this a proper assesment of whats that chunk of code is
> supposed to be doing?

Yes, it should force a new set of session data on login.

> Interesting enough, using "file" session handlers, the old session files
> do not get removed by session_destroy(), and IMP does not change the
> session ID for me on login.   For example, when I submit the "login
> form", I am asked to accept the session cookie 3 times, and the session
> id is the same in all 3 cookies.  I suspect the reason its still
> re-using the old session id is that the session cookie never gets
> changed?  So using "file" sessions, it appears to me that the same
> session ID gets used even after a new login.  The reason the login
> actually "works" using file-based sessions is that the old session file
> is still on disk even though we called session_destroy().

You may want to compare the Horde 2.0 and Horde 3.0-HEAD 
implementations of this
and see if there are any differences that'd explain the behavior you're 
seeing.

> In the SQL driver, session_destroy() does a "DELETE" query to blow away
> the old session record.  So after getCleanSession(), we still have the
> same session_id, but the session data was DELETEd from teh database.

Shouldn't be a problem, since it'll just be created again.

> So in my setup, the only reason things work using "file" based sessions
> is because the session files do not get removed by session_destroy().
> However, the SQL driver *does* remove the session data so that is why it
> fails.  If I make the SQL driver skip the DELETE query, then sql
> sessions work.  Of course, in this case, its behaving just like the file
> based session driver though, because its leaving the original session
> data in the database. This would still leave the "session fixation"
> attack open, right?  If so, then the file based session manager is still
> open to this kind of attack because the session id does not change (and
> thus, a new session is not generated) when you submit the imp login
> form.

If that's what's happening, then yes.

> Am I the only one seeing that the session id does not change when the
> login form is submitted?  Or am I misunderstanding the entire situation?
> If my understanding is correct, then is the SQL driver doing the wrong
> thing by doing a DELETE query when session_destroy() is called?

No, that's definitely the right thing to do.

-chuck

--
"Regard my poor demoralized mule!" - Juan Valdez