章 29. 使用 Register Globals

可能 PHP 中最具争议的变化就是从 PHP 4.2.0 版开始配置文件中 register_globals 的默认值从 on 改为 off 了。对此选项的依赖是如此普遍以至于很多人根本不知道它的存在而以为 PHP 本来就是这么工作的。本节会解释用这个指令如何写出不安全的代码，但要知道这个指令本身没有不安全的地方，误用才会。

当 register_globals 打开以后，各种变量都被注入代码，例如来自 HTML 表单的请求变量。再加上 PHP 在使用变量之前是无需进行初始化的，这就使得更容易写出不安全的代码。这是个很艰难的抉择，但 PHP 社区还是决定默认关闭此选项。当打开时，人们使用变量时确实不知道变量是哪里来的，只能想当然。但是 register_globals 的关闭改变了这种代码内部变量和客户端发送的变量混杂在一起的糟糕情况。下面举一个错误使用 register_globals 的例子：

例子 29-1. 错误使用 register_globals = on 的例子
<?php // 当用户合法的时候，赋值 $authorized = true if (authenticated_user()) { $authorized = true; } // 由于并没有事先把 $authorized 初始化为 false， // 当 register_globals 打开时，可能通过GET auth.php?authorized=1 来定义该变量值 // 所以任何人都可以绕过身份验证 if ($authorized) { include "/highly/sensitive/data.php"; } ?>

当 register_globals = on 的时候，上面的代码就会有危险了。如果是 off，$authorized 就不能通过如 URL 请求等方式来改变，这样就好多了，尽管初始化变量是一个良好的编程习惯。比如说，如果在上面的代码执行之前加入 $authorized = false 的话，无论 register_globals 是 on 还是 off 都可以，因为用户状态被初始化为未经认证。

另一个例子是关于会话的。当 register_globals = on 的时候，$username 也可以用在下面的代码中，但要意识到 $username 也可能会从其它途径进来，比如说通过 URL 的 GET。

例子 29-2. 使用会话时同时兼容 register_globals on 和 off 的例子
<?php // 我们不知道 $username 的来源，但很清楚 $_SESSION 是 // 来源于会话数据 if (isset($_SESSION['username'])) { echo "Hello {$_SESSION['username']}"; } else { echo "Hello Guest "; echo "Would you like to login?"; } ?>

采取相应的预防措施以便在伪造变量输入的时候给予警告是完全有可能的。如果事先确切知道变量是哪里来的，就可以检查所提交的数据是否是从不正当的表单提交而来。不过这不能保证变量未被伪造，这需要攻击者去猜测应该怎样去伪造。如果不在乎请求数据来源的话，可以使用 $_REQUEST 数组，它包括了 GET、POST 和 COOKIE 的所有数据。详情可参见本手册的来自 PHP 之外的变量。

例子 29-3. 探测有害变量
<?php if (isset($_COOKIE['MAGIC_COOKIE'])) { // MAGIC_COOKIE 来自 cookie // 这样做是确保是来自 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 { // 这一次请求中并没有设置 MAGIC_COOKIE 变量 } ?>

当然，单纯地关闭 register_globals 并不代表所有的代码都安全了。对于每一段提交上来的数据，都要对其进行具体的检查。永远要验证用户数据和对变量进行初始化！把 error_reporting() 设为 E_NOTICE 级别可以检查未初始化的变量。

更多关于模拟 register_globals 为 on 或 off 的信息，请见此 FAQ。

Superglobals 可用性说明: 自 PHP 4.1.0 起，可以使用超全局数组变量例如 $_GET，$_POST 和 $_SERVER 等等。更多信息请阅读手册中的 superglobals。

add a note User Contributed Notes

andrei dot neculau (0) gmail dot com
20-May-2006 12:54


If you have a webhost with register_globals On by default, and running PHP as CGI (not as an Apache module, when there might be some solutions) use the code bellow.



Explanation: it will first take all global variables, and unset everything that shouldnt be there. Do not worry about your code still being accesible for changes (i.e. info.php?_ENV[OS]=NewOS ). The PHP queue works like this: first it registers variables from GET, etc. and then it fills in the global variables _GET, _POST, etc. (I wonder why they are not READ ONLY!) Therefore you will have the correct associative arrays, without any injected modification.



<?php



if (ini_get('register_globals'))

{

    foreach($GLOBALS as $s_variable_name => $m_variable_value)

    {

        if (!in_array($s_variable_name, array('GLOBALS', 'argv', 'argc', '_FILES', '_COOKIE', '_POST', '_GET', '_SERVER', '_ENV', '_SESSION', 's_variable_name', 'm_variable_value')))

        {

            unset($GLOBALS[$s_variable_name]);

        }

    }

    unset($GLOBALS['s_variable_name']);

    unset($GLOBLAS['m_variable_value']);

}



?>



Full article here: http://andreineculau.wordpress.com/?s=register_globals



* the above code is not mine. I found it on the Internet, while I was looking for a solution.

alan at xensource dot com
16-Nov-2005 01:00


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 at dexpark dot com
06-Nov-2005 10:59


For Apache users or webhosters, you can set the

php_flag register_globals on/off in a VirtualHost context.

dyer85 at gmail dot com
05-Nov-2005 02:10


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

hbinduni at gmail dot com
30-Oct-2005 05:06


[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.

ramosa (0) gmail dotty com
25-Sep-2005 12:24


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"] : "";

argentus at ukr dot net
14-Aug-2005 05:04


I have found out a method which seems to me the best. I've written my own version of extract. It works as follows:



<?php



safe_extract($_POST, "post", array("param1", "param2"));



// and now I can use the following variables:



echo "param1 is <b>$post_param1_html</b><br />";



mysql_query("SELECT * FROM sometable WHERE something = '$post_param2_slashes'");



if($post_param1_unsafe != $post_param2_unsafe)

// do something.



?>



I think it to be more convenient than using the required functions manually and more safe than that, and surely much more safe than register_globals = On.



The code is very simple. You can write your own version, of course, but I'll also show mine:



<?php



    function make_variables($key, $value, $prefix)

    {

        $GLOBALS["{$prefix}_{$key}_unsafe"] = $value;

        $GLOBALS["{$prefix}_{$key}_slashes"] = addslashes($value);

        $GLOBALS["{$prefix}_{$key}_url"] = urlencode($value);

        $GLOBALS["{$prefix}_{$key}_html"] = htmlspecialchars($value);

        $GLOBALS["{$prefix}_{$key}_url_html"] = htmlspecialchars(urlencode($value));

    }



    function safe_extract($array, $prefix, $keys)

    {

        if(count(array_diff(array_values($keys), array_keys($array))) != 0)

            return false;



        foreach($keys as $key)

            make_variables($key, $array[$key], $prefix);



        return true;

        

    }

?>

kcinick at ciudad dot com dot ar
19-May-2005 06:12


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

ryanwray at gmail dot com
24-Nov-2004 11:03


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.

ben at nullcreations dot net
23-Nov-2004 08:53


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.

snarkles <anything at $myname dot net>
20-May-2004 03:06


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. :\

dav at thedevelopersalliance dot com
18-Dec-2003 02:38


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.

add a note