PHP 安全编程建议

简介

要提供互联网服务，当你在开发代码的时候必须时刻保持安全意识。可能大部分 PHP 脚本都对安全问题都不在意，这很大程度上是因为有大量的无经验程序员在使用这门语言。但是，没有理由让你因为对你的代码的不确定性而导致不一致的安全策略。当你在服务器上放任何涉及到钱的东西时，就有可能会有人尝试破解它。创建一个论坛程序或者任何形式的购物车，被攻击的可能性就上升到了无穷大。

背景

为了确保你的 web 内容安全，这里有一些常规的安全准则：

别相信表单

攻击表单很简单。通过使用一个简单的 JavaScript 技巧，你可以限制你的表单只允许在评分域中填写 1 到 5 的数字。如果有人关闭了他们浏览器的 JavaScript 功能或者提交自定义的表单数据，你客户端的验证就失败了。

用户主要通过表单参数和你的脚本交互，因此他们是最大的安全风险。你应该学到什么呢？在 PHP 脚本中，总是要验证 传递给任何 PHP 脚本的数据。在本文中，我们向你演示了如何分析和防范跨站脚本（XSS）攻击，它可能会劫持用户凭据（甚至更严重）。你也会看到如何防止会玷污或毁坏你数据的 MySQL 注入攻击。

别相信用户

假定你网站获取的每一份数据都充满了有害的代码。清理每一部分，即便你相信没有人会尝试攻击你的站点。

关闭全局变量

你可能会有的最大安全漏洞是启用了 register_globals 配置参数。幸运的是，PHP 4.2 及以后版本默认关闭了这个配置。如果打开了 register_globals，你可以在你的 php.ini 文件中通过改变 register_globals 变量为 Off 关闭该功能：

register_globals = Off 

新手程序员觉得注册全局变量很方便，但他们不会意识到这个设置有多么危险。一个启用了全局变量的服务器会自动为全局变量赋任何形式的参数。为了了解它如何工作以及为什么有危险，让我们来看一个例子。

假设你有一个称为 process.php 的脚本，它会向你的数据库插入表单数据。初始的表单像下面这样：

运行 process.php 的时候，启用了注册全局变量的 PHP 会将该参数赋值到 $username 变量。这会比通过 $_POST[‘username’] 或 $_GET[‘username’] 访问它节省击键次数。不幸的是，这也会给你留下安全问题，因为 PHP 会设置该变量的值为通过 GET 或 POST 的参数发送到脚本的任何值，如果你没有显示地初始化该变量并且你不希望任何人去操作它，这就会有一个大问题。

看下面的脚本，假如 $authorized 变量的值为 true，它会给用户显示通过验证的数据。正常情况下，只有当用户正确通过了这个假想的 authenticated_user() 函数验证，$authorized 变量的值才会被设置为真。但是如果你启用了 register_globals，任何人都可以发送一个 GET 参数，例如 authorized=1 去覆盖它：

这个故事的寓意是，你应该从预定义的服务器变量中获取表单数据。所有通过 post 表单传递到你 web 页面的数据都会自动保存到一个称为 $_POST 的大数组中，所有的 GET 数据都保存在 $_GET 大数组中。文件上传信息保存在一个称为 $_FILES 的特殊数据中。另外，还有一个称为 $_REQUEST 的复合变量。

要从一个 POST 方法表单中访问 username 字段，可以使用 $_POST[‘username’]。如果 username 在 URL 中就使用 $_GET[‘username’]。如果你不确定值来自哪里，用 $_REQUEST[‘username’]。

$_REQUEST 是 $_GET、$_POST、和 $_COOKIE 数组的结合。如果你有两个或多个值有相同的参数名称，注意 PHP 会使用哪个。默认的顺序是 cookie、POST、然后是 GET。

推荐安全配置选项

这里有几个会影响安全功能的 PHP 配置设置。下面是一些显然应该用于生产服务器的：

• register_globals 设置为 off
• safe_mode 设置为 off
• error_reporting 设置为 off。如果出现错误了，这会向用户浏览器发送可见的错误报告信息。对于生产服务器，使用错误日志代替。开发服务器如果在防火墙后面就可以启用错误日志。（LCTT 译注：此处据原文逻辑和常识，应该是“开发服务器如果在防火墙后面就可以启用错误报告，即 on。”）
• 停用这些函数：system()、exec()、passthru()、shell_exec()、proc_open()、和 popen()。
• open_basedir 为 /tmp（以便保存会话信息）目录和 web 根目录，以便脚本不能访问这些选定区域外的文件。
• expose_php 设置为 off。该功能会向 Apache 头添加包含版本号的 PHP 签名。
• allow_url_fopen 设置为 off。如果你能够注意你代码中访问文件的方式-也就是你验证所有输入参数，这并不严格需要。
• allow_url_include 设置为 off。对于任何人来说，实在没有明智的理由会想要访问通过 HTTP 包含的文件。

一般来说，如果你发现想要使用这些功能的代码，你就不应该相信它。尤其要小心会使用类似 system() 函数的代码-它几乎肯定有缺陷。

启用了这些设置后，让我们来看看一些特定的攻击以及能帮助你保护你服务器的方法。

SQL 注入攻击

由于 PHP 传递到 MySQL 数据库的查询语句是用强大的 SQL 编程语言编写的，就有了某些人通过在 web 查询参数中使用 MySQL 语句尝试 SQL 注入攻击的风险。通过在参数中插入有害的 SQL 代码片段，攻击者会尝试进入（或破坏）你的服务器。

假如说你有一个最终会放入变量 $product 的表单参数，你使用了类似下面的 SQL 语句：

$sql = "select * from pinfo where product = '$product'";

如果参数是直接从表单中获得的，应该使用 PHP 自带的数据库特定转义函数，类似：

$sql = 'Select * from pinfo where product = '"' 
       mysql_real_escape_string($product) . '"';

如果不这样做的话，有人也许会把下面的代码段放到表单参数中：

39'; DROP pinfo; SELECT 'FOO 

那么 $sql 的结果就是：

select product from pinfo where product = '39'; DROP pinfo; SELECT 'FOO' 

由于分号是 MySQL 的语句分隔符，数据库会运行下面三条语句：

select * from pinfo where product = '39'
DROP pinfo
SELECT 'FOO' 

好了，你丢失了你的表。

注意实际上 PHP 和 MySQL 不会运行这种特殊语法，因为 mysql_query() 函数只允许每个请求处理一个语句。但是，一个子查询仍然会生效。

要防止 SQL 注入攻击，做这两件事：

• 总是验证所有参数。例如，如果需要一个数字，就要确保它是一个数字。
• 总是对数据使用 mysql_real_escape_string() 函数转义数据中的任何引号和双引号。

注意：要自动转义任何表单数据，可以启用魔术引号（Magic Quotes）。

一些 MySQL 破坏可以通过限制 MySQL 用户权限避免。任何 MySQL 账户可以限制为只允许对选定的表进行特定类型的查询。例如，你可以创建只能选择行的 MySQL 用户。但是，这对于动态数据并不十分有用，另外，如果你有敏感的用户信息，可能某些人能访问其中一些数据，但你并不希望如此。例如，一个访问账户数据的用户可能会尝试注入访问另一个人的账户号码的代码，而不是为当前会话指定的号码。

防止基本的 XSS 攻击

XSS 表示跨站脚本。不像大部分攻击，该漏洞发生在客户端。XSS 最常见的基本形式是在用户提交的内容中放入 JavaScript 以便偷取用户 cookie 中的数据。由于大部分站点使用 cookie 和 session 验证访客，偷取的数据可用于模拟该用户-如果是一个常见的用户账户就会深受麻烦，如果是管理员账户甚至是彻底的惨败。如果你不在站点中使用 cookie 和 session ID，你的用户就不容易被攻击，但你仍然应该明白这种攻击是如何工作的。

不像 MySQL 注入攻击，XSS 攻击很难预防。Yahoo、eBay、Apple、以及 Microsoft 都曾经受 XSS 影响。尽管攻击不包含 PHP，但你可以使用 PHP 来剥离用户数据以防止攻击。为了防止 XSS 攻击，你应该限制和过滤用户提交给你站点的数据。正是因为这个原因，大部分在线公告板都不允许在提交的数据中使用 HTML 标签，而是用自定义的标签格式代替，例如 [b] 和 [linkto]。

让我们来看一个如何防止这类攻击的简单脚本。对于更完善的解决办法，可以使用 SafeHTML，本文的后面部分会讨论到。

function transform_HTML($string, $length = null) {
// Helps prevent XSS attacks
    // Remove dead space.
    $string = trim($string);
    // Prevent potential Unicode codec problems.
    $string = utf8_decode($string);
    // HTMLize HTML-specific characters.
    $string = htmlentities($string, ENT_NOQUOTES);
    $string = str_replace("#", "#", $string);
    $string = str_replace("%", "%", $string);
    $length = intval($length);
    if ($length > 0) {
        $string = substr($string, 0, $length);
    }
    return $string;
} 

这个函数将 HTML 特定的字符转换为 HTML 字面字符。一个浏览器对任何通过这个脚本的 HTML 以非标记的文本呈现。例如，考虑下面的 HTML 字符串：

Bold Text

一般情况下，HTML 会显示为：Bold Text

但是，通过 transform_HTML() 后，它就像原始输入一样呈现。原因是处理的字符串中的标签字符串转换为 HTML 实体。transform_HTML() 的结果字符串的纯文本看起来像下面这样：

Bold Text 

该函数的实质是 htmlentities() 函数调用，它会将 、和 & 转换为 、和 &。尽管这会处理大部分的普通攻击，但有经验的 XSS 攻击者有另一种把戏：用十六进制或 UTF-8 编码恶意脚本，而不是采用普通的 ASCII 文本，从而希望能绕过你的过滤器。他们可以在 URL 的 GET 变量中发送代码，告诉浏览器，“这是十六进制代码，你能帮我运行吗？” 一个十六进制例子看起来像这样：

浏览器渲染这个信息的时候，结果就是：

为了防止这种情况，transform_HTML() 采用额外的步骤把 # 和 % 符号转换为它们的实体，从而避免十六进制攻击，并转换 UTF-8 编码的数据。

最后，为了防止某些人用很长的输入超载字符串从而导致某些东西崩溃，你可以添加一个可选的 $length 参数来截取你指定最大长度的字符串。

使用 SafeHTML

之前脚本的问题比较简单，它不允许任何类型的用户标记。不幸的是，这里有上百种方法能使 JavaScript 跳过用户的过滤器，并且要从用户输入中剥离全部 HTML，还没有方法可以防止这种情况。

当前，没有任何一个脚本能保证无法被破解，尽管有一些确实比大部分要好。有白名单和黑名单两种方法加固安全，白名单比较简单而且更加有效。

一个白名单解决方案是 PixelApes 的 SafeHTML 反跨站脚本解析器。

SafeHTML 能识别有效 HTML，能追踪并剥离任何危险标签。它用另一个称为 HTMLSax 的软件包进行解析。

按照下面步骤安装和使用 SafeHTML：

这是一个完整的例子：