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

[Michael Schout]

On Wed, 11 Aug 2004, Chuck Hagenbuch wrote:

> Quoting Michael Schout <mschout at gkg.net>:
>
> > Apparently, this is the change that breaks SQL session handlers.  If I
> > remove the lines that were added in IMP 3.2.2, (the getCleanSession()
> > call), then everything works perfectly.
> >
> > I dont know enough about the logic as to why this change was made in IMP
> > 3.2.2, and I dont know why it breaks SQL sessions.  But if I remove the
> > getCleanSession() call, it fixes the problem.
>
> No, it simply makes you vulnerable to session fixation attacks; the problem is
> still there, routed around. Look later on in getCleanSession(); it calls
> setupSessionHandler() to reinitialize custom session handlers.
> Obviously that's
> not working for you; you need to find out why.

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

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?

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().

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.

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.

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?

Regards,
Michael Schout