NukeCops

23.4.5. Cookies - timeout and configuration

PHP-Nuke makes heavy use of cookies, be it for user authentication, or admin authentication. The cookies are text files that are saved on our computers and contain various information that is read when we enter a certain site. In the case of PHP-Nuke the information saved there pertains to the user, the chosen theme and the language used.

The cookie is also the instrument that enables us not to have to retype the password each time we log in. This way, each time we access a PHP-Nuke site, the cookie works for us by managing the login operation.

23.4.5.1. Cookie hijack

The problem is that if the cookie does not have an expiry date low enough, someone can to steal it from us and be able to access the site as a user or administrator. This is possible for a series of reasons:

The cookie of PHP-Nuke has a life duration close to infinite (31536000 seconds)
Explorer (most used browser, unfortunately) has vulnerabilities that allow the execution of malicious scripts on the client that "steal" the cookie from the user and send it to the "burglar".
PHP-Nuke does not succeed in filtering all the malicious scripts (or, to put it better, Internet Explorer is so stupid that corrects inserted scripts with the wrong syntax in order not to be recognized).

Let's show a concrete example of how a script kiddie (those who hold themselves for hackers, but they are not...) can try to obtain administrator rights on our site:

The script kiddie inserts a script that supposedly contains news:
< vb script give the cookie to me and send it to the server xyz>
that is not filtered by the function check_words() of PHP-Nuke.
The administrator of PHP-Nuke opens the page up with Internet Explorer!!! (This hack does not work if you're using Mozilla, or better yet, any Linux browser). The list of the news waiting to be approved for publishing is seen by the administrator. When he goes to look at the Submissions, Internet Explorer (stupidly) corrects the vbscript in this way:
<vbscript>(script kiddies commands go here)
succeeding to interpret the wrong syntax in the correct way (!!!), taking the cookie and sending it to the script kiddie.
The script kiddie puts the cookie among the other ones of his own, connects to the site and... is recognized as being the administartor!!!

But how is it possible to protect ourselves from this type of hack?

There are some solutions that should increase the security for our administration area:

First of all STOP using Internet Explorer as a browser and pass the seat to Mozilla. Mozilla is a browser that supports all sites in an optimal way and is not plagued by all the vulnerabilities of Microsoft. If you use Linux instead you won't encounter any problems of this sort...
1. In case you want to continue to use the Explorer, you should at least download the patches from Microsoft.
Disable, where possible, the insertion of HTML tags (for example in the forum)

Narrow down the life of cookies. If for example we set up the life of the cookie to two hours, the script kiddie will be forced to use the cookie within that period, this limits much of their ability to act in time.

If instead we leave the life of the cookie to its preset value, the script kiddie may use our cookie even for 1 month after it was stolen.

How to set up the duration of the administartor cookie? The cookie is set up in the file includes/auth.php and the function to modify it is the following:

if ((isset($aid)) && (isset($pwd)) && ($op == "login")) {
    if($aid! = "" AND $pwd!="") {
        $pwd = md5($pwd);
        $result=sql_query("select pwd, admlanguage from "$prefix."_authors  where aid='$aid'", $dbi);
        list($pass, $admlanguage)=sql_fetch_row($result, $dbi);
        if($pass == $pwd) {
            $admin = base64_encode("$aid:$pwd:$admlanguage");
            setcookie("admin", "$admin",time()+7200);
            unset($op);
        }
    }
}

As you see we have modified the life duration of the second cookie from 2592000 (a month) to 7200 seconds (two hours). As you can easily see, we have reduced the action radius of the script kiddie down from one month to two hours.

A much more effective tag filter is realized through the check_html and filter_text functions in mainfile.php (see Section 16.1). The admissible tags are defined in in the file config.php in the $AllowableHTML array, these are valid for the comments, the insertion of news and many other user inputs (see Table 16-1 and Table 16-2 for all instances of a call to the filter_text and check_html functions respectively).

All these actions and a correct configuration of the permissions as illustrated in Section 3.2.3 and Section 23.4.4, should guarantee us a good security for our site. It is also important to closely follow the security warnings for PHP-Nuke that are brought up on the various security advisories (see Section 23.4.1).

23.4.5.2. Changing the duration of the user cookie

If you want to redefine the duration of the user cookie (as opposed to the administrator cookie), you have to edit the file modules/Your_Account/index.php. There, find the function docookie():

function docookie($setuid, $setusername, $setpass, $setstorynum, $setumode, 
$setuorder, $setthold, $setnoscore, $setublockon, $settheme, $setcommentmax) {
    $info = base64_encode("$setuid:$setusername:$setpass:$setstorynum:$setumode:
$setuorder:$setthold:$setnoscore:$setublockon:$settheme:$setcommentmax");
    setcookie("user","$info",time()+2592000);
}

and change the 2592000 seconds (30 days) to the duration of your choice.

If you want the user cookie to expire as soon as the user closes his browser, to avoid problems with internet cafes and similar situations where a user might forget to log off your site and leave his browser still running, thus making it trivial for others to use his PHP-Nuke account, you should set a temporary cookie. This is done by removing the time altogether:

setcookie("user","$info");

See:

for discussions on this subject.