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. This page will explain how one can write insecure code with this directive but keep in mind that the directive itself isn't insecure but rather it's the misuse of it.
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. When on, people use variables yet really don't know for sure where they come from and can only assume. Internal variables that are defined in the script itself get mixed up with request data sent by users and disabling register_globals changes this. Let's demonstrate with an example misuse of register_globals:
Example 29-1. Example misuse with register_globals = on
When register_globals = on, our logic above may be compromised. When
$authorized can't be set via request so it'll
be fine, although it really is generally a good programming practice to
initialize variables first. For example, in our example above we might
have first done $authorized = false. Doing this
first means our above code would work with register_globals on or off as
users by default would be unauthorized.
Another example is that of sessions.
When register_globals = on, we could also use
$username in our example below but again you must
$username could also come from other
means, such as GET (through the URL).
Example 29-2. Example use of sessions with register_globals on or off
It's even possible to take preventative measures to warn when forging is
being attempted. If you know ahead of time exactly where a variable
should be coming from, you can check to see if the submitted data is
coming from an inappropriate kind of submission. While it doesn't
guarantee that data has not been forged, it does require an attacker to
guess the right kind of forging. If you don't care where the request
data comes from, you can use
$_REQUEST as it contains
a mix of GET, POST and COOKIE data. See also the manual section on
using variables from outside
Example 29-3. Detecting simple variable poisoning
Of course, simply turning off register_globals does not mean your code is secure. For every piece of data that is submitted, it should also be checked in other ways. Always validate your user data and initialize your variables! To check for uninitialized variables you may turn up error_reporting() to show E_NOTICE level errors.
For information about emulating register_globals being On or Off, see this FAQ.
Superglobals: availability note: Since PHP 4.1.0, superglobal arrays such as
$_SERVER, etc. have been available. For more information, read the manual section on superglobals