理解 PHP 及其安全问题的基础知识
有时候，您的业务可能涉及到 PHP 应用程序的安全性。当您遇到审计任务时，您知道如何执行查找吗？本系列将带您进入 PHP，并帮您在一定程序上了解它，让您在进行安全审计时知道查找什么。第 1 部分向您介绍 register_globals 设置。
入门知识
我在此假定您对 PHP 的语法有一个大致的了解，至少能够编写“Hello World”之类的程序。如果您不具备基础知识，则请首先学习 PHP 手册和某些基本的 PHP 教程（参阅 参考资料）。很多出版商都有关于 PHP 的好书。建议初学者一开始先看看入门书籍或食谱形式的书籍。
在生产环境的准确副本上执行审计。您不需要复制硬件，但是需要确保软件版本尽量和实际的完全一样。PHP 配置必须精确匹配，这一点在 php.ini 文件中、在 .htaccess 文件的 Apache 指令中或在 httpd.conf 中已经指定。您需要准备一个单独的环境，因为您将显示和记录可能包含敏感的密码及其他信息的错误。此外，您将尝试中断站点的安全性，这一点是您在活动应用程序中极力避免的。
第一步是将 PHP 的 error_reporting 设置更改为 E_ALL。设置更改后，每当使用未初始化的变量、进行错误的文件访问及发生其他（大多数）无害错误时，PHP 都会报告一条警告消息，但也存在这是一个潜在攻击矢量的可能性。这些错误一般情况下只是表明编程草率，所以如果这是您的代码，您把它们清除掉即可。
该设置如下所示：
|
如果您不知道 php.ini 文件在哪里，则可以通过创建包含以下文本的 .php 脚本来查找：
|
输出的上面部分有一行列出了 PHP 查找 php.ini 的位置：
图 1. PHP 查找 php.ini 的位置
值可能会有些变化，但 /usr/local/lib/php.ini 是大多数 UNIX® 系统上的公共位置，C:\php\php.ini 或 C:\WINDOWS\php.ini 是大多数 Microsoft® Windows® 系统上的公共位置。如果该文件不存在，则创建一个并在文件中键入上面的 error_reporting 行即可。修改 php.ini 文件后，需要重启 Web 服务器，PHP 才能启用新设置。
如果您以前没有创建 phpinfo() 页面，则可以现在创建。第二个主要部分的标签是“配置”，它包含许多关于如何设置 PHP 的有用信息。该部分包括三列：设置名称、本地值 和 xmaster 值。主值是通过 php.ini 指令为您机器上的所有 PHP 脚本全局设置的值。本地值是对当前脚本生效的值。对它有影响的有：.htaccess 设置、httpd.conf 的 <Location> 或 <Directory> 部分中的设置和 PHP 脚本中的 ini_set 调用。在运行时，只有某些设置是可更改的。请参阅 参考资料中的 PHP 手册以获取详细信息。
还需要自定义的另外两种设置是 display_errors 和 log_errors。您至少需要启用这两种设置中的一种，或者两种都启用。log_errors 通知 PHP 将注意、警告或错误记录在文件中，display_errors 将这些被记录下来的注意、警告和错误显示在屏幕上。它们不互相排斥。至少启用它们中的一个，可以有效地发现可能导致安全漏洞的编程错误。
应该查找哪些种类的安全问题？
值得庆幸的是，导致安全漏洞的很多编程错误在 PHP 中不可能存在。堆栈和缓冲溢出是 C 和 C++ 环境中两个常见的问题。因为 PHP 可以为您管理记忆，所以 PHP 代码不会导致堆栈和缓冲溢出。
然而，PHP 本身也是使用 C 语言编写的，有时记忆问题深至 PHP 的核面。因此，您需要时时关注安全公报和更新。PHP 在其 Web 站点（参见 参考资料）公布新 PHP 版本并说明是否包含安全修补程序。
PHP 应用程序中的大多数问题与使用用户提供的数据有关，在使用它和对它执行操作前未曾预先验证和消毒。您可能听说过称为 cross-site scripting (XSS) 的漏洞。XSS 通过提供程序不期望的输入，然后利用程序对无赖输入的处理方式发动进攻。编写良好的程序可以避免这些假定。在机场安全方面，PHP 程序用于检查旅客的行李。
其他问题是一些细微的逻辑错误。例如，检查一系列参数，看看是否批准某个用户访问某种资源、是否把括弧放错位置以至于某些用户进入了他们原本不该到的地方。我们希望您的应用程序组织良好并具有这种集中式逻辑。
识别用户输入
最棘手的一件事情是如何从外部源（如某个用户、别的 Web 站点或某些其他资源）和已经验证的数据中区分出不受信任的输入。有人提出了“不相信一切”的观点，即不管来自何处，对于所有函数都要验证其数据。这一做法会牵涉到以下几件事情：第一，验证在不同的上下文中意味着不同的事情；第二，在应用程序的所有级别上快速执行验证是一件枯燥乏味和易于出错的事情；第三，您是在审计应用程序而不是在从头重新编写它。您需要通过现有代码来跟踪用户输入，而不能用验证函数包装您看到的每个变量。
不期望的用户输入
用户输入从何而来？第一个源是 GET、POST 和 COOKIE 数据。一般称为 GPC 数据。此数据的可识别程序依赖于一个有争议的 php.ini 设置：register_globals。在 PHP V4.3.0 以后，register_globals 默认情况下被设置为 Off。但是几年前，在 PHP 中，register_globals 的默认值是打开的，所以存在很多需要它的代码。
register_globals 本身并非安全风险。但是，它为跟踪用户输入和确保应用程序安全增加了难度。为什么会这样？因为如果打开 register_globals，在全局名称空间和 $_GET、$_POST 或 $_COOKIE 数组中，将创建 GET、POST 和 COOKIE 传递到 PHP 脚本的所有变量。
下面是工作方式及其重要性的示例：
清单 1.COOKIE 的安全性 |
您应该注意几件事。第一，依靠 cookie 来判断用户是否已通过身份验证不是个好主意 —— 因为人们可以很容易地设置自己的 cookie 值。我们将在另外一篇文章中叙述这一点。无论如何，此脚本的缺点在于，如果打开 register_globals，它就不具备安全性了。
下面介绍名为 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 检查更改为以下形式即可：
清单 2. 使用COOKIE 提高安全性 |
这时，当用户将 ?authorized=1 添加到脚本 URL 时，$authorized 变量仍然被设置为 1 —— 但是它随即会被 $authorized = false 覆盖，只有那些实际具有秘密 cookie 的用户才能看到受限的 press 发行版。他们仍然可以设计自己的 cookie。
审计代码的教训：设法关闭 register_globals。如果不打开 register_globals 应用程序就不能运行，并且您无法修改它，或者在应用程序必须运行的地方您无法控制 PHP 配置，则需要在条件块中查找所有全局变量设置，或者通过某些函数调用进入全局范围。如果 register_globals 为打开状态，则这两种情形都是由用户将变量设置为任意值引起的。
找到这些变量的好办法是将 php.ini 设置 error_reporting 设置为 E_ALL，同时使用 log_errors 或 display_errors，这样，所有 PHP 警告和错误都会被分别记录在文件中或显示在屏幕上。每当使用未初始化的变量（假定具有值）时，您将得到一条 E_NOTICE。这像 C 和 Java™ 语言中那样，仍然与让 PHP 要求声明 变量有所不同。结果，当我们的第一个版本的脚本运行时，出现的错误消息是：
|
只要用户没有权限，错误就发生在第 15 行，而不是起初设置变量的第 5 行。PHP 在布尔上下文中将不确定的变量解释为假（参阅 参考资料 中列出的 PHP 手册中的“类型强制转换”），这样代码无论如何都会“正常运行”了 —— 除非有人暗中使用别的方式定义 $authorized。
期望的用户输入
上面说的是不期望的用户输入。下一次，我们将谈论您期望用户输入，但不 期望输入值时的情况。
……