PHP security ---- use Register Globals

The most controversial change in using Register Globals in PHP is that the default value of register_globals in the configuration file is changed from on to off from PHP & raquo; 4.2.0. The dependency on this option is so common that many people do not know its existence and think that PHP is working like this. This section explains how to use this command to write Insecure code, but you must know that this command is not safe and misuse it.
After register_globals is enabled, various variables are injected with code, such as request variables from HTML forms. In addition, PHP does not require initialization before using variables, which makes it easier to write Insecure code. This is a tough decision, but the PHP community decided to disable this option by default. When you open a variable, people do not know where it comes from when using it. However, the close of register_globals changes the bad situation where the internal variables of this Code are mixed with the variables sent by the client. The following is an example of using register_globals incorrectly:
Example #1 Example of register_globals = on Error
<? Php
// If the user is valid, the value $ authorized = true is assigned.
If (authenticated_user ()){
$ Authorized = true;
}

// Because $ authorized is not initialized to false in advance,
// When register_globals is enabled, it may use GET auth. php? Authorized = 1 to define the variable value
// Anyone can bypass authentication.
If ($ authorized ){
Include "/highly/sensitive/data. php ";
}
?>

When register_globals = on, the above Code is dangerous. If it is off, $ authorized cannot be changed through URL request or other methods, which is much better, even though initialization variables are a good programming habit. For example, if $ authorized = false is added before the preceding code is executed, it can be used whether register_globals is on or off, because the user status is initialized to unauthenticated.
Another example is about session. When register_globals = on, $ username can also be used in the following code, but you must realize that $ username may also come in through other methods, such as GET through URL.
Example #2 Examples of compatibility with register_globals on and off when using sessions
<? Php
// We do not know the source of $ username, but it is clear that $ _ SESSION is
// Source session data
If (isset ($ _ SESSION [username]) {

Echo "Hello <B >{$ _ SESSION [username]} </B> ";

} Else {

Echo "Hello <B> Guest </B> <br/> ";
Echo "wocould you like to login? ";

}
?>

It is entirely possible to take appropriate preventive measures so that a warning is given when a variable input is forged. If you know exactly where the variable comes from, you can check whether the submitted data is submitted from an improper form. However, this does not ensure that the variables are not forged, which requires attackers to guess how to forge them. If you do not care about the REQUEST data source, you can use the $ _ REQUEST array, which includes all the data of GET, POST, and COOKIE. For more information, see variables outside of PHP in this manual.
Example #3 detect harmful Variables
<? Php
If (isset ($ _ COOKIE [MAGIC_COOKIE]) {

// MAGIC_COOKIE from cookie
// This ensures that the data is from the cookie.

} Elseif (isset ($ _ GET [MAGIC_COOKIE]) | isset ($ _ POST [MAGIC_COOKIE]) {

Mail ("admin@example.com", "Possible breakin attempt", $ _ SERVER [REMOTE_ADDR]);
Echo "Security violation, admin has been alerted .";
Exit;

} Else {

// The MAGIC_COOKIE variable is not set in this request.

}
?>

Of course, simply disabling register_globals does not mean that all the code is safe. For each piece of submitted data, you must perform a specific check on it. Always verify user data and initialize variables! Set error_reporting () to E_NOTICE to check uninitialized variables.