| Securing PHP Code | | Print | |
At the end of this chapter, we will provide you with some common security flaws in PHP code and show you how to avoid them. We will also cover some general security issues that are independent from PHP.
Register_Globals
The php.ini setting register_globals = On is believed to be one of the reasons why PHP has so many fans nowadays. Working with form data, cookies, or sessions was so easyjust use $name, and you had access. Unfortunately, this also made many users create really stupid code. Following is one example, a modified version of the password checks from earlier in the chapter:
if ($name == "php5" && $pass == "cool") {
$auth = true;
}
if ($auth) {
$_SESSION["username"] = $user;
// now, the redirection stuff
// ...
}
At first glance, this code works well. If the wrong username/password combination is provided, the variable $auth is not set and the session variable is not created. However, what if a malicious (or experimenting) user were to call this script like this: http://servername/login.php?auth=1what would be the effect?
The answer is that because of the GET variable auth, the variable $auth would already exist, the user would be believed as already logged in, and the session variable would be set. A security compromise was achieved by adding seven characters to a URL.
Some might say that the basic reason for the security flaw is that the variable $auth has not been initialized yet. And yes, if the code is changed so that $auth has a default value of false, the exploit does not work any longer:
$auth = false;
if ($name == "php5" && $pass == "cool") {
$auth = true;
}
if ($auth) {
$_SESSION["username"] = $user;
// now, the redirection stuff
// ...
}
However, there is danger right around the corner. If register_globals is set to on, the check whether a user is already logged in could be changed, as wellfrom
if (!isset($_SESSION["username"])) {
to
if (!isset($username)) {
You might guess how this could be overcome: http://servername/page.php?username=Bill. All you wanted is to access the session variable username, but $username does also grant access to the GET variable username, enabling the exploit.
Therefore, one recommendation for secure PHP code is to turn register_globals off. This has the following advantages:
-
No more cheap exploits by adding data to the URL.
-
You then have to explicitly access the variable using $_GET, $_POST, $_COOKIE, $_SERVER, and so on. If you want to read out a cookie, you get only cookies, no GET or POST data.
-
Using $_GET, $_POST, and the like works independently of the PHP configuration. If you rely, however, on register_globals and your hosting partner decides to turn this feature off, you have to rewrite your code.
It has to be noted that the decision to turn register_globals off by default (introduced in PHP version 4.2.0) was not an easy one; many core developers found that an unnecessary step. The most prominent one is Rasmus Lerdorf, himself, by the way.
Although this configuration change was noted with bold letters in the release note and also mentioned on the home page, there are still articles from 2003 where globals are used. The authors obviously have a rather old PHP installation, with globals still turned on. New users, on the other hand, have globals turned off, and the scripts will not work. So make it better than bad authorsturn register_globals off on all your machines. You may have to type a little bit more, but your script then should work almost everywhere.
TIPIf you do want to use globals, one secret is that the PHP function import_request_variables() converts the superglobals into the variable names you once were used to. |
