PHP Security Programming: Register_globals Security

If you can remember early Web application development using C to develop CGI programs, it will certainly be a tedious form of processing deep experience. When the PHP register_globals configuration option is turned on, the complex original form processing is no longer present, and the common variables are created automatically. It makes PHP programming easy and convenient, but it also poses a security risk.

Where does user input come from? The first source is a GET, POST, and COOKIE data. Generally referred to as GPC data. The identifiable program for this data relies on a controversial php.ini setting: Register_globals. After PHP V4.3.0, Register_globals is set to OFF by default. But a few years ago, in PHP, the default value for Register_globals was open, so there was a lot of code that needed it.

In fact, Register_globals is innocent, it does not create loopholes, but also to the developers to make mistakes. However, there are two main reasons why you must turn off register_globals when developing and deployment applications:

• First, it will increase the number of security vulnerabilities;
• Second, it hides the source of the data and violates the responsibility of the developer to keep track of the data.

Register_globals is not a security risk in itself. However, it makes it more difficult to track user input and ensure application security. Why is that? Because if you open register_globals, in the global namespace and in the $_get, $_post, or $_cookie arrays, all the variables that get, POST, and COOKIE are passed to the PHP script are created.

Here's an example of how it works and how important it is:

1<?PHP2 3 //If the user has the secret cookie.4 if(!Empty($_cookie[' Secret '])) {5    $authorized=true;6 }7 8 //Now let's go through a list of press releases and show them.9 $releases=get_press_releases ();Ten foreach($releases  as $release) { One  A     //Some releases is restricted. Only show them to people who can - //See secrets. -     if($release[' Secret ']) { the         if(!$authorized) { -             Continue; -         } -     } +  -     //We must is allowed to see it. +Showrelease ($release); A } at?>

You should pay attention to a few things. First, it's not a good idea to rely on cookies to determine whether a user has been authenticated-because people can easily set their own cookie values. We will describe this in a separate article. In any case, the downside of this script is that if you turn on register_globals, it doesn't have security.

The script named press.php is described below. In general, when a user accesses a script in the press release, their browser will display http://www.example.com/company/press.php.

Now notice what happens when the user changes it to http://www.example.com/company/press.php?authorized=1?

Look at the previous code: set the $authorized only if the user is using a cookie. It will never be set to false. Later, register_globals--was introduced to replace the $_get[' authorized ', which was just used, and a variable with a value of 1 existed at the global scope $authorized. Therefore, even if the user does not pass a cookie check, $authorized later referenced in the Foreach loop will still be verified as true.

There are two ways to fix this flaw. One, of course, is to close register_globals. This is a good idea if you close it without affecting your production site. You need to test the application to make sure it doesn't run as a result.

The other way is a bit like "defensive programming." We only need to change the cookie check to the following form:

 1  <? php  2  //   4   $authorized  = false   5   Empty  ($_cookie  [' Secret ' 

At this point, when the user adds the. authorized=1 to the script URL, the $authorized variable is still set to a "no" but it is overwritten by the $authorized = False, only users who actually have a secret cookie can see the restricted PR ESS release. They can still design their own cookies.

The lesson of the audit code: try to close the register_globals. If you cannot run the register_globals application without opening it, and you cannot modify it, or you cannot control the PHP configuration where the application must run, you will need to find all the global variable settings in the condition block. or through some function calls into the global scope. If Register_globals is open, both of these situations are caused by the user setting the variable to any value.

A good way to find these variables is to set the php.ini setting error_reporting to E_all and use log_errors or display_errors, so that all PHP warnings and errors are recorded in the file or displayed on the screen respectively. You get a e_notice whenever you use an uninitialized variable (assuming you have a value). Is this like C and Java? Language, it is still different from having the PHP requirement declaring variables. As a result, when our first version of the script runs, the error message that appears is:

1 notice:undefined variable:authorized in C:var\www\articles\press.  2 on line 15

As long as the user does not have permissions, the error occurs on line 15th instead of the 5th line of the variable at first. PHP interprets indeterminate variables in Boolean contexts as false (see "type casts" in the PHP manuals listed in resources), so that the code will "work" anyway-unless someone implicitly defines the $authorized in a different way.

If you have to develop an application in the Register_globals open environment, it is important that you initialize all the variables and set the error_reporting to E_all (or E_all | E_STRICT) to warn about uninitialized variables. When Register_globals is turned on, any behavior that uses uninitialized variables almost means a security breach.

PHP Security Programming: Register_globals Security