View Full Version : register_globals = On ???
whl626
01-09-2005, 22:56/10:56PM
As my host has changed the system configuration, the php files in my site stopped to work not until I was advised to make a php.ini file with the above command being added.
May I know what this command is all about ?
bigDugan
01-09-2005, 23:05/11:05PM
Perhaps the most controversial change in PHP is when the default value for the PHP directive register_globals went from ON to OFF in PHP 4.2.0. Reliance on this directive was quite common and many people didn't even know it existed and assumed it's just how PHP works.When on, register_globals will inject your scripts with all sorts of variables, like request variables from HTML forms. This coupled with the fact that PHP doesn't require variable initialization means writing insecure code is that much easier. It was a difficult decision, but the PHP community decided to disable this directive by default. As quoted from: PHP: Using Register Globals (http://us3.php.net/register_globals).
g1smd
02-09-2005, 07:11/07:11AM
Make sure you check that people cannot add extra variables to the ends of your URLs and use them to hack your site.
Check all data coming from external variables carefully, and strip any unwanted stuff off.
whl626
02-09-2005, 09:09/09:09AM
I see, but I learn that this scenario often happens in dynamic sites, right ? Since it allows people to type something in like what it does in a forum or chat room.
Well, the host is turning the register_globals off, that means they are protecting themselves from being attacks ? And individual site using php has to create php.ini with register_globals On to use all the variable functions ?
I don't know if what I ask makes sense ? I am a programming illiterate :D
bigDugan
02-09-2005, 12:02/12:02PM
Originally posted by whl626
I don't know if what I ask makes sense ? I am a programming illiterate :D And apparently cant read very well either. ;) As stated above: it looks like there was PHP upgrade in which the DEFAULT value went from ON to OFF, and has nothing to do with your host trying to protect themselves. Since the directive name contains the word "global", I'm guessing that you only need this if you are using GLOBAL variables, and probably not needed for LOCAL vars (if such).
ArmenT
04-09-2005, 02:43/02:43AM
BigDugan, you haven't explained the actual issue either.
<BEGIN TECH TALK>
The problem really is that if the URL is like this:
www.somedomain.com?q=value1&r=value2
The PHP code would be able to access the values of q and r in code directly like this with register_globals turned on:
$q
$r
etc.
Why is this a problem? Because it allows people to set PHP variable values in the query string. And because some people wrote crappy code like this:
if ($valid_user == 1) {
// The user is authenticated
// do something here
}
without setting $valid_user correctly before the if statement, it could be possible for people to pass this in the query string themselves and gain access:
http://www.domain.com?valid_user=1
Of course, it needs a slightly careless person to code like this, but the world is filled with crappy PHP wannabes who think they're the greatest programmers to have ever walked the earth.
To save wannabes from themselves, the PHP community turned register_globals off by default. Thus, people can't set $valid_user from the query string directly. Instead, to access variables in the query string, the programmer would have to explictly declare something like:
$q = $_GET['q'];
$r = $_GET['r'];
so no one can set arbitrary variables from the query string with register_globals turned off.
<END TECH TALK>
Trouble is that there is a lot of software that was coded assuming register_globals turned on. Instead of people fixing their code to work correctly with register_globals turned off, most people tell website owners to turn register_globals back to On and go from there. Sorry state of affairs really, because they don't warn them about potential issues. By the way, register_globals has been turned off for a few years now.
vBulletin® v3.7.3, Copyright ©2000-2008, Jelsoft Enterprises Ltd.