login_auth plugin - a couple of bugs (with fixes)

[Keith Dunnett]

Summary:

Using the login_auth plugin, if I navigate away from squirrelmail
without properly signing out and then try to return to the page, I get
“Unknown user or password incorrect”. The same error then persists on
trying to refresh or reload the page. The plugin works fine when first
logging in or if I correctly sign out before leaving squirrelmail.

Details:

The problem occurs when we try to create an imap connection in
src/redirect.php. The session variable ‘user_is_logged_in’ gets unset,
so we try to log the user in again. The hook ‘login_before’ is called
but does not succeed in setting $login_username or $secretkey to
anything useful, because it can’t get the relevant variables
$login_auth, $login_auth_pass and $login_auth_user from SQ_SESSION. I’m
guessing that the relevant session has been destroyed before this hook
is called.
Present in squirrelmail 1.4.4 (the current Debian version) with PHP
4.3.10 on a standard Debian sarge install. Not tested against anything else.

Fix (or at least workaround... there may well be a better way):

I’m not sure that the session is not being destroyed for a good reason,
and I’d sooner change the plugin than the workings of squirrelmail. So,
we will make the assumption that if the login_auth plugin is loaded and
if PHP_AUTH_USER and PHP_AUTH_PASS are set, then we must surely want to
use them, and stop placing any reliance on the existence of a
squirrelmail session.

function login_auth_login_before_do()

{
global $just_logged_in, $login_username, $secretkey;
sqgetGlobalVar('PHP_AUTH_USER', $PHP_AUTH_USER, SQ_SERVER);
sqgetGlobalVar('PHP_AUTH_PW', $PHP_AUTH_PW, SQ_SERVER);
if (empty($PHP_AUTH_USER) || empty($PHP_AUTH_PW))
return;
$login_username = $PHP_AUTH_USER;
$secretkey = $PHP_AUTH_PW;
$just_logged_in = 1;
}

Other thoughts:

The use of HTTP authentication fundamentally breaks the Sign Out
function and we should not be telling users that they are successfully
signed out when clicking on Login will take them straight back in with
no further security checks. We should display an alternative signout
page when login_auth is used, telling users that they must close the
browser in order to log out. We might as well refrain from destroying
the session in this case too, so that if they hit the Back button they
get straight back in (which they would via the Login link anyway, so
it's no loss in security terms).

An updated version with fixes for both is at
http://xenon.dunnett.org/login_auth2.1-1.4.x.tar.gz

Comments welcome.

Regards,

Keith







-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
--
squirrelmail-plugins mailing list
Posting Guidelines: http://www.squirrelmail.org/wiki/MailingListPostingGuidelines
List Address: squirrelmail-plugins@...
List Archives: http://news.gmane.org/thread.php?group=gmane.mail.squirrelmail.plugins
List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id931
List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-plugins

[Paul Lesniewski]

Sorry for the late reply, and thank you for your contribution.  I have
some comments:

> Summary:
>
> Using the login_auth plugin, if I navigate away from squirrelmail without
> properly signing out and then try to return to the page, I get "Unknown user
> or password incorrect". The same error then persists on trying to refresh or
> reload the page. The plugin works fine when first logging in or if I
> correctly sign out before leaving squirrelmail.
>
> Details:
>
> The problem occurs when we try to create an imap connection in
> src/redirect.php.

I fail to see why you would ever return to src/redirect.php unless you
first returned to src/login.php, in which case the plugin will go to
work again from the beginning and work the same as when you first
brought up SM.  I cannot reproduce this issue no matter what I try.
Going back to any other page works as normal.  Are you speaking of
having gone off so long that the PHP session dies?  Let me try
that....  well I do get a "you need an account to access this page"
error and a link to the login page, but clicking the link logs the
user in automatically as before, which seems fine.  The session having
died is a natural process, and we do in fact need to go back through
the login process to generate a new one.  I suppose we could force
that automatically in the case of login errors, although when the http
user/pwd does not match the SM one, we'd be caught in a neverending
loop, so I'm inclined to leave it as is.

Suffice to say: I cannot see the problem you do and see no need for
any fix.  src/redirect.php is only ever accessed from the login page
(and should normally never even appear in the browser history), in
which case the plugin works as designed.

> The session variable 'user_is_logged_in' gets unset, so we
> try to log the user in again. The hook 'login_before' is called but does not
> succeed in setting $login_username or $secretkey to anything useful, because
> it can't get the relevant variables $login_auth, $login_auth_pass and
> $login_auth_user from SQ_SESSION. I'm guessing that the relevant session has
> been destroyed before this hook is called.
> Present in squirrelmail 1.4.4 (the current Debian version) with PHP 4.3.10
> on a standard Debian sarge install. Not tested against anything else.
>
> Fix (or at least workaround... there may well be a better way):
>
> I'm not sure that the session is not being destroyed for a good reason, and
> I'd sooner change the plugin than the workings of squirrelmail. So, we will
> make the assumption that if the login_auth plugin is loaded and if
> PHP_AUTH_USER and PHP_AUTH_PASS are set, then we must surely want to use
> them, and stop placing any reliance on the existence of a squirrelmail
> session.
>
> function login_auth_login_before_do()
>
> {
> global $just_logged_in, $login_username, $secretkey;
> sqgetGlobalVar('PHP_AUTH_USER', $PHP_AUTH_USER, SQ_SERVER);
> sqgetGlobalVar('PHP_AUTH_PW', $PHP_AUTH_PW, SQ_SERVER);
> if (empty($PHP_AUTH_USER) || empty($PHP_AUTH_PW))
> return;
> $login_username = $PHP_AUTH_USER;
> $secretkey = $PHP_AUTH_PW;
> $just_logged_in = 1;
> }
>
> Other thoughts:
>
> The use of HTTP authentication fundamentally breaks the Sign Out function
> and we should not be telling users that they are successfully signed out
> when clicking on Login will take them straight back in with no further
> security checks. We should display an alternative signout page when
> login_auth is used, telling users that they must close the browser in order
> to log out. We might as well refrain from destroying the session in this
> case too, so that if they hit the Back button they get straight back in
> (which they would via the Login link anyway, so it's no loss in security
> terms).

I agree.  I am adding code that overrides the $signout_page config var
if there was nothing there already with a custom page that says so
much.  Thanks for pointing that out.

> An updated version with fixes for both is at
> http://xenon.dunnett.org/login_auth2.1-1.4.x.tar.gz

Dead link

> Comments welcome.
>
> Regards,
>
> Keith
>

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
-----
squirrelmail-plugins mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-plugins@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.plugins
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-plugins