podo
12-07-2004, 09:23 PM
Hey there,
In the past, I've noticed that a few other forum members indulge in the great delight of coding PHP. I've also noticed that many of the forum members host their web applications with Hetzner Africa. However, I am unsure if many of the members are aware of a little known, potentially dangerous, and easily corrected problem, which might occur when running PHP scripts on Hetzner's servers, or any other hosting provider, for that matter.
For the benifit of all my PHP coding brethren, I feel I should post this, all though very much off topic, it just might help.
While training users today on a PHP based application I have been developing over the past few months, a completely unexpected error suddenly occurred, causing session management to malfunction completely. Stunned, I first tried to find the error in the code, nothing, then, I tried the same page on my development server, no problem. After about four hours of searching through the code, I was still left with no answers.
At that point, I decided I should start checking for differences between my development server and the server at the ISP hosting the web site, in this case, Hetzner Africa. At first, I was eluded by the answer yet again, as Hetzner were running the exact same versions of Apache, MySQL and PHP as I.
Then, I decided to check the output of phpinfo() on both servers. After comparing the values, I found that Hetzner have the old register_globals setting turned on for PHP on their servers.
register_globals is a (now) seldom used setting which makes PHP register all values from GET or POST operations, as well as the elements from $_SERVER and $_SESSION as global variables. In all recent versions of PHP, this setting is off by default, as the introduction of $_GET and $_POST, and the rest of the pre-defined superglobal arrays have caused it to become deprecated, and because it can pose a serious security risk in scripts that or not well thought out.
Hetzner must still turn on this variable, because it is required by the osCommerce shopping cart system, which Hetzner installs for all customers with "standard" or better hosting accounts. The dependency on register_globals obviously does not bode well for osCommerce, but the developers are working toward a new release where the need for register_globals will no longer exist. However, at the present time, it is still needed, and as such, enabled by default on Hetzner's servers.
To test the effect of the setting, I proceded to enable register_globals on my development server. Immediately, the same problem arose.
After some digging, I realised that the problem is simple. In session management, I use the $_SESSION['user'] variable to store the username of an authenticated user in the $_SESSION hash, thus storing it in the session cookie and allowing transparent authentication to work.
In the part of the application where the error occurred, I was using the variable $user to store data on individual users while composing a table.
Obviously, since PHP was registering all elements from the $_SESSION hash as global variables, my innocent use of $user to store information, inadvertently overwrote the $_SESSION['user'] variable, causing the cookie to become corrupt, and session management to fail.
While I could have fixed the problem by finding all variables in my entire 200+ script file application, and making sure they do not correspond to something that PHP might register as a global from one of the hashes in question, this would have been a tremendous waste of time, and the security risk would still exist if I had missed a variable, or a future developer, unaware of the problem, were to introduce a variable which caused another conflict.
Luckily, the solution to my problem was quite simple. The developers of PHP had the wonderful good sence to make the register_globals setting changable on a per-directory basis. All I had to do to get my application working properly on the hosting server was to turn off register_globals for my directory.
A warning to all my fellow PHP geeks. If you're hosting with Hetzner, make sure you turn off register_globals for your directory, to avoid any nasty surprises.
To do so is quite simple. In each directory of your web site where PHP scripts reside, simply create a .htaccess file, containing the following line:
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">
php_value register_globals 0
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Hope this helps somebody down the road somewhere.
Willie Viljoen
Web Developer
Adaptive Web Development
In the past, I've noticed that a few other forum members indulge in the great delight of coding PHP. I've also noticed that many of the forum members host their web applications with Hetzner Africa. However, I am unsure if many of the members are aware of a little known, potentially dangerous, and easily corrected problem, which might occur when running PHP scripts on Hetzner's servers, or any other hosting provider, for that matter.
For the benifit of all my PHP coding brethren, I feel I should post this, all though very much off topic, it just might help.
While training users today on a PHP based application I have been developing over the past few months, a completely unexpected error suddenly occurred, causing session management to malfunction completely. Stunned, I first tried to find the error in the code, nothing, then, I tried the same page on my development server, no problem. After about four hours of searching through the code, I was still left with no answers.
At that point, I decided I should start checking for differences between my development server and the server at the ISP hosting the web site, in this case, Hetzner Africa. At first, I was eluded by the answer yet again, as Hetzner were running the exact same versions of Apache, MySQL and PHP as I.
Then, I decided to check the output of phpinfo() on both servers. After comparing the values, I found that Hetzner have the old register_globals setting turned on for PHP on their servers.
register_globals is a (now) seldom used setting which makes PHP register all values from GET or POST operations, as well as the elements from $_SERVER and $_SESSION as global variables. In all recent versions of PHP, this setting is off by default, as the introduction of $_GET and $_POST, and the rest of the pre-defined superglobal arrays have caused it to become deprecated, and because it can pose a serious security risk in scripts that or not well thought out.
Hetzner must still turn on this variable, because it is required by the osCommerce shopping cart system, which Hetzner installs for all customers with "standard" or better hosting accounts. The dependency on register_globals obviously does not bode well for osCommerce, but the developers are working toward a new release where the need for register_globals will no longer exist. However, at the present time, it is still needed, and as such, enabled by default on Hetzner's servers.
To test the effect of the setting, I proceded to enable register_globals on my development server. Immediately, the same problem arose.
After some digging, I realised that the problem is simple. In session management, I use the $_SESSION['user'] variable to store the username of an authenticated user in the $_SESSION hash, thus storing it in the session cookie and allowing transparent authentication to work.
In the part of the application where the error occurred, I was using the variable $user to store data on individual users while composing a table.
Obviously, since PHP was registering all elements from the $_SESSION hash as global variables, my innocent use of $user to store information, inadvertently overwrote the $_SESSION['user'] variable, causing the cookie to become corrupt, and session management to fail.
While I could have fixed the problem by finding all variables in my entire 200+ script file application, and making sure they do not correspond to something that PHP might register as a global from one of the hashes in question, this would have been a tremendous waste of time, and the security risk would still exist if I had missed a variable, or a future developer, unaware of the problem, were to introduce a variable which caused another conflict.
Luckily, the solution to my problem was quite simple. The developers of PHP had the wonderful good sence to make the register_globals setting changable on a per-directory basis. All I had to do to get my application working properly on the hosting server was to turn off register_globals for my directory.
A warning to all my fellow PHP geeks. If you're hosting with Hetzner, make sure you turn off register_globals for your directory, to avoid any nasty surprises.
To do so is quite simple. In each directory of your web site where PHP scripts reside, simply create a .htaccess file, containing the following line:
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">
php_value register_globals 0
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Hope this helps somebody down the road somewhere.
Willie Viljoen
Web Developer
Adaptive Web Development