PHP 应用程序的安全 -- 不能违反的四条安全规则

开始之前

在本教程中，您将学习如何在自己的PHPWeb应用程序中添加安全性。本教程假设您至少有一年编写PHPWeb应用程序的经验，所以这里不涉及PHP语言的基本知识（约定或语法）。目标是使您了解应该如何保护自己构建的Web应用程序。

目标
本教程讲解如何防御最常见的安全威胁：SQL注入、操纵GET和POST变量、缓冲区溢出攻击、跨站点脚本攻击、浏览器内的数据操纵和远程表单提交。

前提条件
本教程是为至少有一年编程经验的PHP开发人员编写的。您应该了解PHP的语法和约定；这里不解释这些内容。有使用其他语言（比如Ruby、Python和Perl）的经验的开发人员也能够从本教程中受益，因为这里讨论的许多规则也适用于其他语言和环境。

系统需求

需要一个正在运行PHPV4或V5和MySQL的环境。可以使用Linux、OSX或MicrosoftWindows。如果是在Windows上，那么下载WAMPServer二进制文件，在机器上安装Apache、MySQL和PHP。

安全性快速简介
Web应用程序最重要的部分是什么？根据回答问题的人不同，对这个问题的答案可能是五花八门。业务人员需要可靠性和可伸缩性。IT支持团队需要健壮的可维护的代码。最终用户需要漂亮的用户界面和执行任务时的高性能。但是，如果回答“安全性”，那么每个人都会同意这对Web应用程序很重要。

但是，大多数讨论到此就打住了。尽管安全性在项目的检查表中，但是往往到了项目交付之前才开始考虑解决安全性问题。采用这种方式的Web应用程序项目的数量多得惊人。开发人员工作几个月，只在最后才添加安全特性，从而让Web应用程序能够向公众开放。

结果往往是一片混乱，甚至需要返工，因为代码已经经过检验、单元测试并集成为更大的框架，之后才在其中添加安全特性。添加安全性之后，主要组件可能会停止工作。安全性的集成使得原本顺畅（但不安全）的过程增加额外负担或步骤。

本教程提供一种将安全性集成到PHPWeb应用程序中的好方法。它讨论几个一般性安全主题，然后深入讨论主要的安全漏洞以及如何堵住它们。在学完本教程之后，您会对安全性有更好的理解。

主题包括：
SQL注入攻击
操纵GET字符串
缓冲区溢出攻击
跨站点脚本攻击（XSS）
浏览器内的数据操纵
远程表单提交

Web安全性101
在讨论实现安全性的细节之前，最好从比较高的角度讨论Web应用程序安全性。本节介绍安全哲学的一些基本信条，无论正在创建何种Web应用程序，都应该牢记这些信条。这些思想的一部分来自ChrisShiflett（他关于PHP安全性的书是无价的宝库），一些来自SimsonGarfinkel（参见参考资料），还有一些来自多年积累的知识。

规则1：绝不要信任外部数据或输入

关于Web应用程序安全性，必须认识到的第一件事是不应该信任外部数据。外部数据（outsidedata）包括不是由程序员在PHP代码中直接输入的任何数据。在采取措施确保安全之前，来自任何其他来源（比如GET变量、表单POST、数据库、配置文件、会话变量或cookie）的任何数据都是不可信任的。

例如，下面的数据元素可以被认为是安全的，因为它们是在PHP中设置的。

清单1.安全无暇的代码

$myUsername='tmyer';
$arrayUsers=array('tmyer','tom','tommy');
define("GREETING",'hellothere'.$myUsername);
?>

但是，下面的数据元素都是有瑕疵的。

清单2.不安全、有瑕疵的代码

$myUsername=$_POST['username'];//tainted!
$arrayUsers=array($myUsername,'tom','tommy');//tainted!
define("GREETING",'hellothere'.$myUsername);//tainted!
?>

为什么第一个变量$myUsername是有瑕疵的？因为它直接来自表单POST。用户可以在这个输入域中输入任何字符串，包括用来清除文件或运行以前上传的文件的恶意命令。您可能会问，“难道不能使用只接受字母A-Z的客户端（JavaScript）表单检验脚本来避免这种危险吗？”是的，这总是一个有好处的步骤，但是正如在后面会看到的，任何人都可以将任何表单下载到自己的机器上，修改它，然后重新提交他们需要的任何内容。

解决方案很简单：必须对$_POST['username']运行清理代码。如果不这么做，那么在使用$myUsername的任何其他时候（比如在数组或常量中），就可能污染这些对象。

对用户输入进行清理的一个简单方法是，使用正则表达式来处理它。在这个示例中，只希望接受字母。将字符串限制为特定数量的字符，或者要求所有字母都是小写的，这可能也是个好主意。

清单3.使用户输入变得安全

$myUsername=cleanInput($_POST['username']);//clean!
$arrayUsers=array($myUsername,'tom','tommy');//clean!
define("GREETING",'hellothere'.$myUsername);//clean!

functioncleanInput($input){
$clean=strtolower($input);
$clean=preg_replace("/[^a-z]/","",$clean);
$clean=substr($clean,0,12);
return$clean;
}
?>

规则2：禁用那些使安全性难以实施的PHP设置

已经知道了不能信任用户输入，还应该知道不应该信任机器上配置PHP的方式。例如，要确保禁用register_globals。如果启用了register_globals，就可能做一些粗心的事情，比如使用$variable替换同名的GET或POST字符串。通过禁用这个设置，PHP强迫您在正确的名称空间中引用正确的变量。要使用来自表单POST的变量，应该引用$_POST['variable']。这样就不会将这个特定变量误会成cookie、会话或GET变量。

要检查的第二个设置是错误报告级别。在开发期间，希望获得尽可能多的错误报告，但是在交付项目时，希望将错误记录到日志文件中，而不是显示在屏幕上。为什么呢？因为恶意的黑客会使用错误报告信息（比如SQL错误）来猜测应用程序正在做什么。这种侦察可以帮助黑客突破应用程序。为了堵住这个漏洞，需要编辑php.ini文件，为error_log条目提供合适的目的地，并将display_errors设置为Off。

规则3：如果不能理解它，就不能保护它

一些开发人员使用奇怪的语法，或者将语句组织得很紧凑，形成简短但是含义模糊的代码。这种方式可能效率高，但是如果您不理解代码正在做什么，那么就无法决定如何保护它。

例如，您喜欢下面两段代码中的哪一段？

清单4.使代码容易得到保护

//obfuscatedcode
$input=(isset($_POST['username'])?$_POST['username']:'');

//unobfuscatedcode
$input='';

if(isset($_POST['username'])){
$input=$_POST['username'];
}else{
$input='';
}
?>

在第二个比较清晰的代码段中，很容易看出$input是有瑕疵的，需要进行清理，然后才能安全地处理。

规则4：“纵深防御”是新的法宝

本教程将用示例来说明如何保护在线表单，同时在处理表单的PHP代码中采用必要的措施。同样，即使使用PHPregex来确保GET变量完全是数字的，仍然可以采取措施确保SQL查询使用转义的用户输入。

纵深防御不只是一种好思想，它可以确保您不会陷入严重的麻烦。

既然已经讨论了基本规则，现在就来研究第一种威胁：SQL注入攻击。

防止SQL注入攻击

在SQL注入攻击中，用户通过操纵表单或GET查询字符串，将信息添加到数据库查询中。例如，假设有一个简单的登录数据库。这个数据库中的每个记录都有一个用户名字段和一个密码字段。构建一个登录表单，让用户能够登录。

清单5.简单的登录表单

Username

Password

这个表单接受用户输入的用户名和密码，并将用户输入提交给名为verify.php的文件。在这个文件中，PHP处理来自登录表单的数据，如下所示：

清单6.不安全的PHP表单处理代码

$okay=0;
$username=$_POST['user'];
$pw=$_POST['pw'];

$sql="selectcount(*)asctrfromuserswhereusername='".$username."'andpassword='".$pw."'limit1";

$result=mysql_query($sql);

while($data=mysql_fetch_object($result)){
if($data->ctr==1){
//they'reokaytoentertheapplication!
$okay=1;
}
}

if($okay){
$_SESSION['loginokay']=true;
header("index.php");
}else{
header("login.php");
}
?>

这段代码看起来没问题，对吗？世界各地成百（甚至成千）的PHP/MySQL站点都在使用这样的代码。它错在哪里？好，记装不能信任用户输入”。这里没有对来自用户的任何信息进行转义，因此使应用程序容易受到攻击。具体来说，可能会出现任何类型的SQL注入攻击。

例如，如果用户输入foo作为用户名，输入'or'1'='1作为密码，那么实际上会将以下字符串传递给PHP，然后将查询传递给MySQL：

$sql="selectcount(*)asctrfromuserswhereusername='foo'andpassword=''or'1'='1'limit1";
?>

这个查询总是返回计数值1，因此PHP会允许进行访问。通过在密码字符串的末尾注入某些恶意SQL，黑客就能装扮成合法的用户。

解决这个问题的办法是，将PHP的内置mysql_real_escape_string()函数用作任何用户输入的包装器。这个函数对字符串中的字符进行转义，使字符串不可能传递撇号等特殊字符并让MySQL根据特殊字符进行操作。清单7展示了带转义处理的代码。

清单7.安全的PHP表单处理代码

$okay=0;
$username=$_POST['user'];
$pw=$_POST['pw'];

$sql="selectcount(*)asctrfromuserswhereusername='".mysql_real_escape_string($username)."'andpassword='".mysql_real_escape_string($pw)."'limit1";

$result=mysql_query($sql);

while($data=mysql_fetch_object($result)){
if($data->ctr==1){
//they'reokaytoentertheapplication!
$okay=1;
}
}

if($okay){
$_SESSION['loginokay']=true;
header("index.php");
}else{
header("login.php");
}
?>

使用mysql_real_escape_string()作为用户输入的包装器，就可以避免用户输入中的任何恶意SQL注入。如果用户尝试通过SQL注入传递畸形的密码，那么会将以下查询传递给数据库：

selectcount(*)asctrfromuserswhereusername='foo'andpassword=''or'1'='1'limit1"

数据库中没有任何东西与这样的密码匹配。仅仅采用一个简单的步骤，就堵住了Web应用程序中的一个大漏洞。这里得出的经验是，总是应该对SQL查询的用户输入进行转义。

但是，还有几个安全漏洞需要堵祝下一项是操纵GET变量。

防止用户操纵GET变量

在前一节中，防止了用户使用畸形的密码进行登录。如果您很聪明，应该应用您学到的方法，确保对SQL语句的所有用户输入进行转义。

但是，用户现在已经安全地登录了。用户拥有有效的密码，并不意味着他将按照规则行事——他有很多机会能够造成损害。例如，应用程序可能允许用户查看特殊的内容。所有链接指向template.php?pid=33或template.php?pid=321这样的位置。URL中问号后面的部分称为查询字符串。因为查询字符串直接放在URL中，所以也称为GET查询字符串。

在PHP中，如果禁用了register_globals，那么可以用$_GET['pid']访问这个字符串。在template.php页面中，可能会执行与清单8相似的操作。

清单8.示例template.php

$pid=$_GET['pid'];

//wecreateanobjectofafictionalclassPage
$obj=newPage;
$content=$obj->fetchPage($pid);
//andnowwehaveabunchofPHPthatdisplaysthepage
?>

这里有什么错吗？首先，这里隐含地相信来自浏览器的GET变量pid是安全的。这会怎么样呢？大多数用户没那么聪明，无法构造出语义攻击。但是，如果他们注意到浏览器的URL位置域中的pid=33，就可能开始捣乱。如果他们输入另一个数字，那么可能没问题；但是如果输入别的东西，比如输入SQL命令或某个文件的名称（比如/etc/passwd），或者搞别的恶作剧，比如输入长达3,000个字符的数值，那么会发生什么呢？

在这种情况下，要记住基本规则，不要信任用户输入。应用程序开发人员知道template.php接受的个人标识符（PID）应该是数字，所以可以使用PHP的is_numeric()函数确保不接受非数字的PID，如下所示：

清单9.使用is_numeric()来限制GET变量

$pid=$_GET['pid'];

if(is_numeric($pid)){
//wecreateanobjectofafictionalclassPage
$obj=newPage;
$content=$obj->fetchPage($pid);
//andnowwehaveabunchofPHPthatdisplaysthepage
}else{
//didn'tpasstheis_numeric()test,dosomethingelse!
}
?>

这个方法似乎是有效的，但是以下这些输入都能够轻松地通过is_numeric()的检查：

100（有效）
100.1（不应该有小数位）
+0123.45e6（科学计数法——不好）
0xff33669f（十六进制——危险！危险！）

那么，有安全意识的PHP开发人员应该怎么做呢？多年的经验表明，最好的做法是使用正则表达式来确保整个GET变量由数字组成，如下所示：

清单10.使用正则表达式限制GET变量

$pid=$_GET['pid'];

if(strlen($pid)){
if(!ereg("^[0-9]+$",$pid)){
//dosomethingappropriate,likemaybeloggingthemoutorsendingthembacktohomepage
}
}else{
//empty$pid,sosendthembacktothehomepage
}

//wecreateanobjectofafictionalclassPage,whichisnow
//moderatelyprotectedfromeviluserinput
$obj=newPage;
$content=$obj->fetchPage($pid);
//andnowwehaveabunchofPHPthatdisplaysthepage
?>

需要做的只是使用strlen()检查变量的长度是否非零；如果是，就使用一个全数字正则表达式来确保数据元素是有效的。如果PID包含字母、斜线、点号或任何与十六进制相似的内容，那么这个例程捕获它并将页面从用户活动中屏蔽。如果看一下Page类幕后的情况，就会看到有安全意识的PHP开发人员已经对用户输入$pid进行了转义，从而保护了fetchPage()方法，如下所示：

清单11.对fetchPage()方法进行转义

classPage{
functionfetchPage($pid){
$sql="selectpid,title,desc,kw,content,statusfrompagewherepid='".mysql_real_escape_string($pid)."'";
}
}
?>

您可能会问，“既然已经确保PID是数字，那么为什么还要进行转义？”因为不知道在多少不同的上下文和情况中会使用fetchPage()方法。必须在调用这个方法的所有地方进行保护，而方法中的转义体现了纵深防御的意义。

如果用户尝试输入非常长的数值，比如长达1000个字符，试图发起缓冲区溢出攻击，那么会发生什么呢？下一节更详细地讨论这个问题，但是目前可以添加另一个检查，确保输入的PID具有正确的长度。您知道数据库的pid字段的最大长度是5位，所以可以添加下面的检查。

清单12.使用正则表达式和长度检查来限制GET变量

$pid=$_GET['pid'];

if(strlen($pid)){
if(!ereg("^[0-9]+$",$pid)&&strlen($pid)>5){
//dosomethingappropriate,likemaybeloggingthemoutorsendingthembacktohomepage
}
}else{
//empty$pid,sosendthembacktothehomepage
}
//wecreateanobjectofafictionalclassPage,whichisnow
//evenmoreprotectedfromeviluserinput
$obj=newPage;
$content=$obj->fetchPage($pid);
//andnowwehaveabunchofPHPthatdisplaysthepage
?>

现在，任何人都无法在数据库应用程序中塞进一个5,000位的数值——至少在涉及GET字符串的地方不会有这种情况。想像一下黑客在试图突破您的应用程序而遭到挫折时咬牙切齿的样子吧！而且因为关闭了错误报告，黑客更难进行侦察。

缓冲区溢出攻击

缓冲区溢出攻击试图使PHP应用程序中（或者更精确地说，在Apache或底层操作系统中）的内存分配缓冲区发生溢出。请记住，您可能是使用PHP这样的高级语言来编写Web应用程序，但是最终还是要调用C（在Apache的情况下）。与大多数低级语言一样，C对于内存分配有严格的规则。

缓冲区溢出攻击向缓冲区发送大量数据，使部分数据溢出到相邻的内存缓冲区，从而破坏缓冲区或者重写逻辑。这样就能够造成拒绝服务、破坏数据或者在远程服务器上执行恶意代码。

防止缓冲区溢出攻击的惟一方法是检查所有用户输入的长度。例如，如果有一个表单元素要求输入用户的名字，那么在这个域上添加值为40的maxlength属性，并在后端使用substr()进行检查。清单13给出表单和PHP代码的简短示例。

清单13.检查用户输入的长度

if($_POST['submit']=="go"){
$name=substr($_POST['name'],0,40);
}
?>

"method="post">

Name

为什么既提供maxlength属性，又在后端进行substr()检查？因为纵深防御总是好的。浏览器防止用户输入PHP或MySQL不能安全地处理的超长字符串（想像一下有人试图输入长达1,000个字符的名称），而后端PHP检查会确保没有人远程地或者在浏览器中操纵表单数据。

正如您看到的，这种方式与前一节中使用strlen()检查GET变量pid的长度相似。在这个示例中，忽略长度超过5位的任何输入值，但是也可以很容易地将值截短到适当的长度，如下所示：

清单14.改变输入的GET变量的长度

$pid=$_GET['pid'];

if(strlen($pid)){
if(!ereg("^[0-9]+$",$pid)){
//ifnonnumeric$pid,sendthembacktohomepage
}
}else{
//empty$pid,sosendthembacktothehomepage
}

//wehaveanumericpid,butitmaybetoolong,solet'scheck
if(strlen($pid)>5){
$pid=substr($pid,0,5);
}

//wecreateanobjectofafictionalclassPage,whichisnow
//evenmoreprotectedfromeviluserinput
$obj=newPage;
$content=$obj->fetchPage($pid);
//andnowwehaveabunchofPHPthatdisplaysthepage
?>

注意，缓冲区溢出攻击并不限于长的数字串或字母串。也可能会看到长的十六进制字符串（往往看起来像xA3或xFF）。记住，任何缓冲区溢出攻击的目的都是淹没特定的缓冲区，并将恶意代码或指令放到下一个缓冲区中，从而破坏数据或执行恶意代码。对付十六进制缓冲区溢出最简单的方法也是不允许输入超过特定的长度。

如果您处理的是允许在数据库中输入较长条目的表单文本区，那么无法在客户端轻松地限制数据的长度。在数据到达PHP之后，可以使用正则表达式清除任何像十六进制的字符串。

清单15.防止十六进制字符串

if($_POST['submit']=="go"){
$name=substr($_POST['name'],0,40);
//cleanoutanypotentialhexadecimalcharacters
$name=cleanHex($name);
//continueprocessing....
}

functioncleanHex($input){
$clean=preg_replace("![][xX]([A-Fa-f0-9]{1,3})!","",$input);
return$clean;
}
?>
"method="post">

Name

您可能会发现这一系列操作有点儿太严格了。毕竟，十六进制串有合法的用途，比如输出外语中的字符。如何部署十六进制regex由您自己决定。比较好的策略是，只有在一行中包含过多十六进制串时，或者字符串的字符超过特定数量（比如128或255）时，才删除十六进制串。

跨站点脚本攻击

在跨站点脚本（XSS）攻击中，往往有一个恶意用户在表单中（或通过其他用户输入方式）输入信息，这些输入将恶意的客户端标记插入过程或数据库中。例如，假设站点上有一个简单的来客登记簿程序，让访问者能够留下姓名、电子邮件地址和简短的消息。恶意用户可以利用这个机会插入简短消息之外的东西，比如对于其他用户不合适的图片或将用户重定向到另一个站点的JavaScript，或者窃取cookie信息。

幸运的是，PHP提供了strip_tags()函数，这个函数可以清除任何包围在HTML标记中的内容。strip_tags()函数还允许提供允许标记的列表，比如或。

清单16给出一个示例，这个示例是在前一个示例的基础上构建的。

清单16.从用户输入中清除HTML标记

if($_POST['submit']=="go"){
//strip_tags
$name=strip_tags($_POST['name']);
$name=substr($name,0,40);
//cleanoutanypotentialhexadecimalcharacters
$name=cleanHex($name);
//continueprocessing....
}

functioncleanHex($input){
$clean=preg_replace("![][xX]([A-Fa-f0-9]{1,3})!","",$input);
return$clean;
}
?>
"method="post">

Name