PHP安全编程之register_globals的安全性

小咪咪 2022-07-19 02:25 259阅读 0赞

如果你还能记起早期Web应用开发中使用C开发CGI程序的话，一定会对繁琐的表单处理深有体会。当PHP的register\_globals配置选项打开时，复杂的原始表单处理不复存在，公用变量会自动建立。它让PHP编程变得容易和方便，但同时也带来了安全隐患。

用户输入从何而来？第一个源是 GET、POST 和 COOKIE 数据。一般称为 GPC 数据。此数据的可识别程序依赖于一个有争议的 php.ini设置：register\_globals。在 PHP V4.3.0 以后，register\_globals 默认情况下被设置为 Off。但是几年前，在 PHP 中，register\_globals 的默认值是打开的，所以存在很多需要它的代码。

事实上，register\_globals是无辜的，它并不会产生漏洞，同时还要开发者犯错才行。可是，有两个主要原因导致了您必须在开发和布署应用时关闭register\_globals：

*  第一，它会增加安全漏洞的数量；
 *  第二，隐藏了数据的来源，与开发者需要随时跟踪数据的责任相违背。

register\_globals?本身并非安全风险。但是，它为跟踪用户输入和确保应用程序安全增加了难度。为什么会这样？因为如果打开register\_globals，在全局名称空间和 $\_GET、$\_POST 或 $\_COOKIE 数组中，将创建 GET、POST 和 COOKIE 传递到 PHP 脚本的所有变量。

下面是工作方式及其重要性的示例：

<?php
    
    // See if the user has the secret cookie.
    if (!empty($_COOKIE['secret'])) {
       $authorized = true;
    }
    
    // Now let's go through a list of press releases and show them.
    $releases = get_press_releases();
    foreach ($releases as $release) {
    
        // Some releases are restricted. Only show them to people who can
        // see secrets.
        if ($release['secret']) {
            if (!$authorized) {
                continue;
            }
        }
    
        // We must be allowed to see it.
        showRelease($release);
    }
    ?>

您应该注意几件事。第一，依靠 cookie 来判断用户是否已通过身份验证不是个好主意 —— 因为人们可以很容易地设置自己的 cookie 值。我们将在另外一篇文章中叙述这一点。无论如何，此脚本的缺点在于，如果打开 register\_globals，它就不具备[安全性][Link 1]了。

下面介绍名为 press.php 的脚本。一般来说，当用户访问 press 发行版的脚本时，其浏览器将显示 http://www.example.com/company/press.php。

现在注意当用户擅自将其更改为 http://www.example.com/company/press.php?authorized=1 时将发生什么事？

看看前面的代码：仅当用户使用 cookie 时才设置 $authorized。它永远不会被设置为假。后来引入了 register\_globals —— 它取代了刚才使用的 $\_GET\['authorized'\]，同时在全局范围内还存在一个值为 1 的变量 $authorized。因此，即使用户没有通过 cookie 检查，$authorized 后来在 foreach 循环中引用时，仍然会被验证为真。

修复此缺陷可以使用两种方式。其一，当然是关闭 register\_globals。如果关闭它对您的生产站点没有影响，则这是个好主意。您需要测试一下应用程序，确保它没有因此中断运行。

另一种方式有点像“防御性编程”。我们只需要将 cookie 检查更改为以下形式即可：

<?php
    
    // See if the user has the secret cookie.
    $authorized = false;
    if (!empty($_COOKIE['secret'])) {
       $authorized = true;
    }
    ?>

这时，当用户将 ?authorized=1 添加到脚本 URL 时，$authorized 变量仍然被设置为 1 —— 但是它随即会被 $authorized = false 覆盖，只有那些实际具有秘密 cookie 的用户才能看到受限的 press 发行版。他们仍然可以设计自己的 cookie。

审计代码的教训：设法关闭 register\_globals。如果不打开 [register\_globals][register_globals] 应用程序就不能运行，并且您无法修改它，或者在应用程序必须运行的地方您无法控制 PHP 配置，则需要在条件块中查找所有全局变量设置，或者通过某些函数调用进入全局范围。如果 register\_globals 为打开状态，则这两种情形都是由用户将变量设置为任意值引起的。

找到这些变量的好办法是将 php.ini 设置 error\_reporting 设置为 E\_ALL，同时使用 log\_errors 或 display\_errors，这样，所有 PHP 警告和错误都会被分别记录在文件中或显示在屏幕上。每当使用未初始化的变量（假定具有值）时，您将得到一条 E\_NOTICE。这像 C 和 Java? 语言中那样，仍然与让 PHP 要求声明 变量有所不同。结果，当我们的第一个版本的脚本运行时，出现的错误消息是：

Notice: Undefined variable: authorized in C:\var\www\articles\press.php 
    on line 15

只要用户没有权限，错误就发生在第 15 行，而不是起初设置变量的第 5 行。PHP 在布尔上下文中将不确定的变量解释为假（参阅 参考资料 中列出的 PHP 手册中的“类型强制转换”），这样代码无论如何都会“正常运行”了 —— 除非有人暗中使用别的方式定义 $authorized。

如果您必须要开发一个在register\_globals开启的环境中布署的应用时，很重要的一点是您必须要初始化所有变量并且把error\_reporting 设为 E\_ALL(或 E\_ALL | E\_STRICT)以对未初始化变量进行警告。当register\_globals开启时，任何使用未初始化变量的行为几乎就意味着安全漏洞。

来自:http://www.nowamagic.net/librarys/veda/detail/1978

[Link 1]: http://www.nowamagic.net/librarys/veda/tag/%E5%AE%89%E5%85%A8%E7%BC%96%E7%A8%8B
[register_globals]: http://www.nowamagic.net/librarys/veda/tag/register_globals