Possible Major Security Issue Here !!!!

[techs]

I created a user under the registered group and then another user under another group TEST.

I then created some departments under the default tempate and others under TEST template group.

I login under user in registered and only see departments i should see under registered until i do this.

http://support.mydomain.com/index.ph...ist&group=TEST

Once I do the above and try to submit a ticket I can then see the other departments in another group while i am logged in as a user that is not a member of TEST.

Did I miss something in the configuration or is this an issue?

[supportskins]

You need to change the Template Group setting enabling "Restrict Users Group" setting under:
Admin CP > Templates > Manage Groups > templategroup > Settings > Default User Groups > Restrict Users Group > Yes

[techs]

The setting above doesn't fix the issue. Did you try what I suggested?

This is a security hole and needs attention!!!

[keliix06]

Even if you can see a different group I have a hard time seeing how that is a security issue, let alone a major one. Minor inconvenience at most.

Are you sure the user you are testing with is not a part of a group that has access to the template group you don't want them to have access to?

[Sheep]

Bringing back this topic as i was doing the same test.

This is a critical security hole as ANY user seems to be able to change template with just handling the ?group=<newgroup>. There's currently no checks on the templatechange.

The only way to restrict some content folder/subfolder (downloads, kb - note: i'm not talking about widget) to specific customers are through templates but then if anyone can change freely the template...

Can anyone confirm this is a "bug" and not a missconfiguration?


Edit: if you change the template before loging in, then when you try to log in you'll get denied. the hack comes when you log in the default section then change template using the url GET paremeter.

[Sheep]

This is not an other "bump" but the opposite

Here is a fix i've done.

If the user logged in try to access to a template where he doesn't have access , the system will disconnect his session.
I'm not 100% sure that i work with the good variables as there's no code documentation for the part i'm playing with ($_swift) but it seems to work ...

The following part is based on easymod writing rules

#
#-----[ OPEN ]---------------------------------------------
#
index.php

#
#-----[ FIND ]---------------------------------------------
# around line 68

PHP Code:

 $loginshare->loadPermissions(); // Loads up the permissions for active user group 


#
#-----[ AFTER, ADD ]---------------------------------------
#

PHP Code:

 
    // ======= GROUP ACCESS RIGHT CHECK =======
    if ($_SWIFT["user"]["loggedin"])  
     {
        // Verify that the loaded group is allowed
        $groupok=false;
        foreach ($_SWIFT["tgroupcache"] as $key=>$val)
        {
            if ($val["regusergroupid"] == $_SWIFT["user"]["usergroupid"] && !empty($_SWIFT["user"]["usergroupid"]) && $_SWIFT["tgroup"]["tgroupid"] == $val["tgroupid"])
            {
                // Ok group allowed
                $groupok=true;
                break;
 
            }
        }
        if (!$groupok) 
        {
            // Closing session
            $logoutresult = $loginshare->logout();
 
            // Reset Template Group
            $cookie->parseCookie("client");
            $cookie->addCookie("client", "groupid", false);
            $cookie->buildCookie("client", true);
 
            require_once ("./includes/functions_html.php");   
 
            printRedirect($_SWIFT["language"]["loggingout"], "index.php?logoutresult=".urlencode($logoutresult), true);
            exit;
        }
     } 


#
#-----[ SAVE/CLOSE ALL FILES ]------------------------------------------
#
# EoM

Any comment, fix, insult is welcome

Greetings,
Antoine

Edit: hmmm, i should not use "$_SWIFT["language"]["loggingout"]" as the phrase but a new one... but well... i you want... do it yourself