Delicious Bookmark this on Delicious Share on Facebook SlashdotSlashdot It! Digg! Digg



PHP : Security : Using Register Globals

Chapter 8. Using Register Globals

Warning:

This feature is DEPRECATED and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged.

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 8.1. Example misuse with register_globals = on

copy to clipboard
<?php
// define $authorized = true only if user is authenticated
if (authenticated_user()) {
   $authorized = true;
}

// Because we didn't first initialize $authorized as false, this might be
// defined through register_globals, like from GET auth.php?authorized=1
// So, anyone can be seen as authenticated!
if ($authorized) {
   include "/highly/sensitive/data.php";
}
?>


When register_globals = on, our logic above may be compromised. When off, $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 realize that $username could also come from other means, such as GET (through the URL).

Example 8.2. Example use of sessions with register_globals on or off

copy to clipboard
<?php
// We wouldn't know where $username came from but do know $_SESSION is
// for session data
if (isset($_SESSION['username'])) {

   echo "Hello <b>{$_SESSION['username']}</b>";

} else {

   echo "Hello <b>Guest</b><br />";
   echo "Would you like to login?";

}
?>


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 of PHP.

Example 8.3. Detecting simple variable poisoning

copy to clipboard
<?php
if (isset($_COOKIE['MAGIC_COOKIE'])) {

   // MAGIC_COOKIE comes from a cookie.
   // Be sure to validate the cookie data!

} 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 {

  // MAGIC_COOKIE isn't set through this REQUEST

}
?>


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 $_GET , $_POST, and $_SERVER, etc. have been available. For more information, read the manual section on superglobals

Code Examples / Notes » security.globals

hbinduni
[quote]
If you're under an Apache environment that has this option enabled, but you're on shared hosting so have no access to php.ini, you can unset this value for your own site by placing the following in an .htaccess file in the root:
php_flag register_globals 0
[/quote]
adding php_flag in .htaccess under apache 2 will cause internal server error. according to apache 2 manual, php_flag should goes to <virtual> or <directory> section.

alan hogan
Useful for shared hosting or scripts that you are sharing with other people.
<?php
// Effectively turn off dangerous register_globals without having to edit php.ini
if (ini_get(register_globals))  // If register_globals is enabled
{ // Unset $_GET keys
 foreach ($_GET as $get_key => $get_value) {
   if (ereg('^([a-zA-Z]|_){1}([a-zA-Z0-9]|_)*$', $get_key)) eval("unset(\${$get_key});");
 } // Unset $_POST keys
 foreach ($_POST as $post_key => $post_value) {
   if (ereg('^([a-zA-Z]|_){1}([a-zA-Z0-9]|_)*$', $post_key)) eval("unset(\${$post_key});");
 } // Unset $_REQUEST keys
 foreach ($_REQUEST as $request_key => $request_value) {
   if (ereg('^([a-zA-Z]|_){1}([a-zA-Z0-9]|_)*$', $request_key)) eval("unset(\${$request_key});");
 }
}
?>

caliwebman
U know what I find incredibly insane? The fact that no where on the first pages <<<PLURAL does anyone even suggest where to find this code. And IF it exists in a file called "register_globals-etc..." than I have no clue why none of my sites have this file. It amazes me that we here on this side have made things so incredibly difficult on ourselves and the newer coders. Why? I thought that was what Microsoft was doing but quite honestly follks, we here on this side have MS beat when it comes to making things MUCH more of a challenge than they need be.
PLEASE, please dumb things down. And if you can't? ASK someone who is NOT in your bubble of code to review what you are writing in your dirstructions.... directions.... ask someoen like your MOM or DAD who know nothing of the code.
We sure would get going mch more quickly if we all paid attenttion to this simple rule.... and lastly, the front end designers are finally getting it together..... thank you, but again, remember, THE 3 CLICK RULE!!!
Peace,
Gentle Warrior

mike willbanks
Sorry the last php code I submitted was formatted nice but I changed some things for readability and didn't implement it across the board.  Here is the correct code:
<?php
if (ini_get(register_globals)) {
   $rg = array_keys($_REQUEST);
   foreach($rg as $var)
   {
       if ($_REQUEST[$var] === $$var)
       {
           unset($$var);
       }
   }
}
?>

ben
Just a note to all the people who think $_SESSION can be poisoned by register_globals - it can't.
Consider the fact that GET/POST/COOKIE is Processed *before* sessions are.  This means that even if you have register_globals on, and they write to $_SESSION, $_SESSION will just get reset again with the appropriate values.
Some people take to using extract() as a means to simulate register_globals in scripts where they're not sure what the server environment will be - this is when you should worry about such things.  The reason is because extract() can concievably occur after GET/POST/COOKIE and SESSION processing.

timbo
In response to the above post by Caliwebman at yahoo dot com, a.k.a. "Gentle Warrior" who complained about the lack of documentation on register_globals:
I think this code snippet will address the *main* source of his confusion:
<?
function readyToBeAProgrammer()
{
 $stuff=$_URINALYSIS['test'];
 if($stuff == THC)
 {
   return false;
 }
 else
 {
   return true;
 }
 // register_globals is all about knowing where your variables are really coming from
 // what if a malicious user tried to pass off
 // $stuff=$_GET['someone_elses_drop']; // as $stuff ?
 // preventing this kind of substitution is the whole point
 // of disabling register_globals
}
if(!readyToBeAProgrammer())
{
 die("Switch to coffee, man!");
}
?>
P.S., let's give it up in appreciation for the moderators who must sit though and clean up these boards, facetious posts like mine included...

someone
In reply to yyalcinkaya at ku edu tr you could just do this with $_REQUEST:
foreach($_REQUEST as $k => $v)
{
 ${$k} = $v;
}
...though doing something like this is asking for a world of trouble IMHO.

ryanwray
In reply to ben at nullcreations dot net:
This is true of the super-global $_SESSION, as it will always be processed last (it is not considered in variables_order directive)
However, it is possible to over-write other data, namely GET, POST, COOKIE, ENVIROMENT and SERVER.
Of course, what you can overwrite will depend on the directive variables_order - by default, you could overwrite GET and POST data via COOKIE (because cookie data is processed last out of the three which should not really be of great concern.
My below code is irrelevant unless extract or another method which does the same thing (ie. I have seen variable variables used before to reach the same affect) is used.

dav
import_request_variables() has a good solution to part of this problem - add a prefix to all imported variables, thus almost eliminating the factor of overriding internal variables through requests. you should still check data, but adding a prefix to imports is a start.

snarkles
If you're under an Apache environment that has this option enabled, but you're on shared hosting so have no access to php.ini, you can unset this value for your own site by placing the following in an .htaccess file in the root:
php_flag register_globals 0
The ini_set() function actually accomplishes nothing here, since the variables will have already been created by the time the script processes the ini file change.
And since this is the security chapter, just as a side note, another thing that's helpful to put into your .htaccess is:
<Files ".ht*">
deny from all
</Files>
That way no one can load .htaccess in their browser and have a peek at its contents.
Sorry, not aware of a similar workaround for IIS. :\

yyalcinkaya
if you want to keep register_globals off you can use this codes instead.
foreach($_POST AS $key => $value) {
   ${$key} = $value;
}
foreach($_GET AS $key => $value) {
   ${$key} = $value;
}

kcinick
if you plan to use php_admin_value register_globals [0-1] inside <VirtualHost> in apache, forget it, it don't show any error messages in the configuration, but at the time of running, it enable and disables register_globals at random request, if you need to customize this param to multiple virtual host, put it in a <Directory> directives, it works fine there...
PD: same for safe_mode, etc...

dyer85
I'd suggest taking a look at php.net's source code for these user notes, if you want to get ideas on some nice ways to collect and validate user data.
http://php.net/source.php?url=/manual/add-note.php

scott
I couldn't get any of the suggested ways to disable register_globals to work in what I believe to be an Apache environment, where even phpinfo() is disabled. I finally had to resort to
foreach(array_keys($_REQUEST) as $field)
{
unset(${$field});
}
to get the $_REQUEST array without auto-setting all the request variables. I'm somewhat new to the whole PHP thing and wonder if there is a downside to this that I don't see.

ramosa 0 gmail dotty com
Here's a one liner that works both with register globals on or off, and is even secure enough when it's on, as you make sure you init the var.
Using the ?: operator
$variable = isset($_GET["variable"]) ? $_GET["variable"] : "";

alan
From the PHP Manual page on Using register_globals:
Do not use extract() on untrusted data, like user-input ($_GET, ...). If you do, for example, if you want to run old code that relies on register_globals  temporarily, make sure you use one of the non-overwriting extract_type values such as EXTR_SKIP and be aware that you should extract in the same order that's defined in variables_order within the php.ini.

dexter
For Apache users or webhosters, you can set the
php_flag register_globals on/off in a VirtualHost context.

mike willbanks
Alans code may get rid of globals but it is slow since it is doing regular expressions on each of the input items.  Then to add on more time the code is being passed through eval.
Besides the slower performance, his code is not checking to see if the variable may have been changed at any state before this code is being done.
There might be auto_prepended files or include files that might need to run before it.  He is also going through get and post and lastly request which is a little silly seeing as request will contain the get, post and cookie so he has run get and post twice.
Here is a more effective fix that will take all the keys in request which become variable names and checks to make sure that the variables match then unsets the element.
<?php
if (ini_get(register_globals)) {
$rg = array_keys($_REQUEST);
foreach($rg as $var)
{
if ($_REQUEST[$v] === $$v)
{
unset($$v);
}
}
}
?>

Change Language


Follow Navioo On Twitter
Introduction
General considerations
Installed as CGI binary
Installed as an Apache module
Filesystem Security
Database Security
Error Reporting
Using Register Globals
User Submitted Data
Magic Quotes
Hiding PHP
Keeping Current
Terms of Service Privacy Policy Sitemap

©2024 -EPSILONSYS SOFTWARE inc

Other EPSILONSYS SOFTWARE Web Sites : Programming Resources | News Headline | Free local classifieds

eXTReMe Tracker