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

[Michael M Slusarz]

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.  We made all the
| following changes to our PHP setup, as was recommended in the
| discussions:
|
| php.ini:
| session.use_cookies 1
| session.use_trans_sid 0
| session.entropy_file /dev/urandom
| session.entropy_length 64
|
| Other session-related settings are as follows:
| /etc/php.ini:
| session.gc_maxlifetime = 1440
| session.gc_probability = 1
| session.save_handler = file
| session.save_path = /var/www/tmp
|
| horde.php:
| $conf['session_name'] = 'Horde';
| $conf['cache_limiter'] = 'nocache';
| $conf['session_timeout'] = 0;
|
| We are running the following packages and versions:
| 	Production		Test
| Horde	2.2.1			2.2.3
| IMP 	3.1			3.2.1
| Turba 	1.1 			1.2
|
| Our webserver uses Redhat 7.3, Apache 1.3.27, PHP v. 4.1.2
|
| 	We already know that sessions are being created and garbage-collected
| as one would expect from these configuration settings.  After making the
| changes, we went for about 3 months while without further reports of
| people getting into others' mailboxes at login.
| 	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.

Make sure they are not using a bookmark that contains a session identifier
in it (e.g. http://www.example.com/horde/foo.php?Horde=0123456789)

| 	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
| production and test sites, the only difference being that on the
| production site, the session ID appears in the URI prior to a successful
| login, and on the test site it appears only after a successful login.

This should already be fixed in IMP/HORDE RELENG - we now recreate the
session identifier once you login so the session identifier that appears in
the URL in the login is irrelevant - it can't be used to hijack the
session.

| 	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?

Try HEAD.  These problems have not been reported there (at least so far).

As far as someone putting time into finding a solution... remember that this
is an open source project so 1) no guarantees, and 2) everyone that uses
the software is potentially the person who "puts the time into finding the
fix" :)

michael

______________________________________________
Michael Slusarz [slusarz at bigworm.colorado.edu]
The University of Colorado at Boulder