In older versions of PHP, variables submitted from external sources, e.g. session variables, cookies, form fields, etc, were automatically converted to variables inside PHP, as long as register_globals was enabled, which it was by default. These variables were also accessible through the arrays $HTTP_POST_VARS, $HTTP_COOKIE_VARS, $HTTP_SESSION_VARS, etc.
Imagine the following situation: you have a secure site, where members are identified by logon names, e.g. "Administrator", "Joe", "Peter", etc. The pages on this site track the username by way of the variable UserID, which is stored in a cookie on the computer when the user authenticates to the site.
With register_globals enabled, $UserID is available as a variable to all scripts on your site, which, whilst helpful, is quite a security hole. Take a look at the structure of this URL: http://www.yoursite.com/secure/forum.php?UserID=root
When register_globals is enabled, all variables sent by GET and POST are also converted to variables, and are indistinguishable from variables from other sources. The result of this is that a hacker could, by using the URL above, impersonate someone else - like root!
This was clearly a critical situation, and it was worryingly common. As such, the decision was taken to recommend all users to disable register_globals. In PHP 4.2, this was pushed further by having the default value of register_globals changed to "off", and this is how it has remained in PHP 5. Register_globals is not likely to ever be changed back to "on" for its default value, which means that it is best to learn the proper way of doing things: using the superglobals.
Next chapter: Working around register_globals >>
Previous chapter: Handling data
Home: Table of Contents