Why are we even checking the token before logging in the user?

I am getting this message when trying to implement aggressive varnish caching:

"Sorry, logging in from a different domain is not permitted. Please try again."

I have also noticed other users getting an error message under some cases:

http://community.elgg.org/discussion/view/1264892/elgg-1815-causing-login-errors

And the thought occurs to me: why is it even necessary to validate the token for the user login?  If the username and password is correct why should elgg not just log the user in to the given site?  I am very green to Elgg's internals but I thought I would ask this as I cannot come up with a logical reason.  It seems almost an unecessary complication to me.  Under what case would you *not* want to log the user in assuming the username and password posted were correct?

I'm sure there is probably something simple I am missing. :)

Thank you.

 

  • @ALL:
    The questioning is right !;-P
    Login (and Logout) need never be controlled via any token, gatekeeper, nothing;
    There can never be 'security risk' at those points ;oO.
    So ~ no need for the 'token' verification.

     

  • What is a hacker is at random trying to login? With the requirement of the action tokens this is a little more difficult.

  • With tokens a form will expire in 1 hour. This way a bot can login to your site with a saved form details for  a maximum of 1 hour duration only.

  • Thanks DhrupDeScoop,

    As an experiment I went ahead (i did this on my own so hopefully no one tries to blame you for getting me to hack core. ;) ) and changed engine/lib/actions.php by commenting out two lines in action_gatekeeper() where it specifically has a special case for catching the login case so now it always returns true.

    -----

    function action_gatekeeper($action) {
            if ($action === 'login') {
    //              if (validate_action_token(false)) {
                            return true;
    //              }
                    
                    $token = get_input('__elgg_token');
                    $ts = (int)get_input('__elgg_ts');
                    if ($token && _elgg_validate_token_timestamp($ts)) {
                            // The tokens are present and the time looks valid: this is probably a mismatch due to the
                            // login form being on a different domain.
                            register_error(elgg_echo('actiongatekeeper:crosssitelogin'));


                            forward('login', 'csrf');
                    }

    -------

    This "fixed" the problems I was having with recieving the error message "Sorry, logging in from a different domain is not permitted. Please try again." and it seems fine with my tests so far.  Although the user is not getting a error message now when the password is wrong -- but there is likely a workaround for that (this is likely due to my caching pages for up to 30 minutes in varnish and the complications involved in that).  I'm definitely open to other suggestions and input.  I'm not sure that it is possible to override this behaviour with a plugin, is it?  I'm not sure whether Iwill go with this "solution" or attempt some other workaround.

  • I guess I can see that a little bit.  I notice the reason for it seems to imply in the code that it is related to csrf.  But I don't see how protecting against a login when the requester has the uname and pw is relevant.  Is it related to elggperm perhaps?

    @Team Webgalli,

    That makes sense I guess.  But from what I understand in theory wouldn't that just mean an extra request by the bot once per hour?  It seems like a type of security by obscurity in that you are hoping the bad guy does not realize that the tokens expire in one hour.

    Anyway I admit to my total noobness and ignorance here. :)

  • The main reason i think about the action tokens is CSRF attacks. If action tokens are missing you can even post the form from your localhost, but with the action tokens the form can only be posted from the site it has been generated. i.e from your site.

    The issue you facing might be due to the worng cookie or some old session.

  • @CX, thanks.  I think it's because I am using varnish (reverse proxy) to cache the pages very aggressively.  So there often is no token (elgg cookie) at all for non-logged in users or it is cached and from a previous unvalidated user.  So validate_action_token() fails and action_gatekeeper() assumes it is because the cookie was set on another domain.  And so my users see the error when logging in via the dropdown login box.  I have a series of hacks in place to get things to work such as using a special cookie which is set for users who have logged in before.  The proxy then checks for that cookie and does not cache dynamic pages when it is present and this makes the site 100% functional as normal for logged in users again.

    I'll read up on csrf some more and see if I can figure out the ramifications of what I am doing.  I understand what you all are saying (I think) but I don't see how it provides any meaningful security other than creating a very minor hurdle for the attacker.  I have a lot to learn for sure but am having fun stumbling through this. :)

  • So I made some other modifications and it seems to be working perfectly with the login and register functionality now. No more lack of error_messages for bad passwords and the like. :)  Now I just need to get everything in a custom plugin so I am not hacking core. :/ 

    The only thing I see which looks very troublesome to do is the above modification in actions.php.

    Based on Cash's comment at:

    http://community.elgg.org/discussion/view/554718/should-my-plugin-actions-call-action-gatekeeper

    It seems that action_gatekeeper() is automatically called for all actions.  And the login case is hardcoded within that.  So I appear to be stuck?  Is this truly a case where I must modify core to do this in this way? :/

    I'm not sure of the full csrf implications yet but I have a fully functional site now with varnish aggressively caching and it seems to be really worth it in the load average reduction so far.  I was thinking maybe eventually down the road there could be a "Varnish Helper" plugin for Elgg with many hacks and workarounds to make implementing an extremely aggressive varnish cache easier for Elgg users.

  • Yes action_gatekeeper() is for all action by default. except

    $exceptions = array(
    'admin/plugins/disable',
    'logout',
    'file/download',
    );

    I can't find any hook regarding this so that we can use it a plugin to bypass, so if you want it for login as well, you can add it manually in core file i.e eninge/lib/action.php line 72

  • I think that's the original topic that was reason for introducing tokens requirement for login in Elgg 1.8.14 https://groups.google.com/d/topic/elgg-development/K0SgvjjyK8I/discussion

Beginning Developers

Beginning Developers

This space is for newcomers, who wish to build a new plugin or to customize an existing one to their liking