[imp] Users still getting into other users' mailboxes at login

[Eric Rostetter]

Quoting James Moore <jmoore at thebank.com>:

> 	We were having problems with users getting into other people's
> mailboxes at login, as has been reported elsewhere.

Yes, though I've never seen it at my site.

> php.ini:
> session.use_cookies 1
> session.use_trans_sid 0
> session.entropy_file /dev/urandom
> session.entropy_length 64

Sounds good.

> Other session-related settings are as follows:
> /etc/php.ini:
> session.gc_maxlifetime = 1440
> session.gc_probability = 1

You realize that means there is only a 1% chance that the session will be
"garbage collected" on any given php invocation?

I know that's the default, but it seems stupid to me.  I really recommend
setting it to a much higher percentage (like 25%), unless you know your site
is active enough 24/7 to make the sessions die quickly enough.

I don't know if leaving old sessions around can cause the types of problems
you report, but it surely can't help...

> 	Recently, however, we were informed by a user that she has been getting
> into one other user's mailbox occasionally over the last month.  She
> manages to do this using AOL's browser. Every time it happens, she gets
> into the mailbox without having to attempt a login, and always into the
> mailbox of the same user.  Have not been able to find out from the
> "victim" user how she is invoking the IMP site, or whether she disabled
> cookies in her browser.

One other possible idea is that AOL has a web cache that is playing havok
with things...  Since you say below that your cookies aren't working, and
you are using uri based sessions, this becomes even more plausible.

> 	In a potentially related issue, we are not able to stop session ids
> from being passed in the URI, regardless of how browsers are configured
> (Mozilla 1.2.1, IE 6.0, Netscape 4.7x, 7.x).  This goes for both the

Then you have something misconfigured in your cookies setup...  Using cookies
should increase your security (reduce the kind of problems you report
slightly, but also reduce logging of sessions, history caching, etc).

> 	I have followed all the threads addressing these issues, and at every
> point they come to an end without a satisfactory resolution.  I have a
> simple question:  Has anyone found a verified fix, and if not, when is
> someone going to put some time into finding one?

I think your first thing to do would be to fix the cookie problem.  Then
I'd worry about the actual session issues.

There have been changes to the CVS code to help with session destruction, etc.
They may help in your case.  But I'd try to fix your cookie problem first,
then worry about patches to the session creation/destruction after that.

> Sincerely,
> Jim Moore

--
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Why get even? Get odd!