10.2. The cookies, timeout and configuration

PHPNuke 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 PHPNuke 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 PHPNuke portal, the cookie works for us managing the login operation.

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

1. the cookie of PHPNUke has a life duration close to infinite (31536000 seconds)

2. 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".

3. PHPNuke does not succeed in filtering all the malicious scripts (or, to put it better, the Explorer is so stupid that corrects inserted scripts with a 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 portal:

1. 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 PHPNuke.

2. the administrator of PHPNuke opens (with explorer!!! With Mozilla, or better on linux , this hack it is not valid) the list of the news waiting to be approved for publishing, Explorer (stupid) corrects the vbscript in this way: <vbscript> in all the instructions, succeeding to interpret in the correct way (!!) the wrong syntax, taking the cookie and sending it to the script kiddie.

3. the script kiddie puts the cookie among the other ones of his own, it connects to the site and... he is recognized as being the administartor!!!

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

There is a set of solutions that should increase much the security of our administartion area:

1. In the first place stop using the Internet Explorer as a browser and pass the seat to Mozilla. Mozilla is a browser that supports all the sites in an optimal way and is not plagued by all the vulnerabilities of the house Redmond. Ah! If you instead happen to use Linux, you do not have problems of this sort...

   1. In case you want to continue to use the Explorer, you should at least download the patches from Microsoft.

2. Disable, where possible, the insertion of HTML tags (for example in the forum of Splatt.it)

3. 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 its ability to act.

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

   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 it is easy to see, we have reduced the action radius of the script kiddie down from one month to two hours.

4. A much more effective tag filter is in the study phase, although for the moment, the proposed solutions did give a definitive answer to the problem. The admissible tags are defined in in the file config.php in the variable $AllowableHTML, these are valid for the comments and the insertion of news in the function check_html() which for the moment lets some tags pass through.

All these actions and an correct configuration of the permissions as illustrated in Section 10.1 should guarantee us a good security of our portal. It is also important to follow closely the security warnings for PHPNuke that are brought up on http://neworder.box.sk/.