确保 PHP 应用程序的安全
开始以前
在本教程中，您将学习如何在本身的 PHP Web 应用程序中添加安全性。本教程假设您至少有一年编写 PHP Web 应用程序的经验，因此这里不涉及 PHP 语言的基本知识（约定或语法）。目标是使您了解应该如何保护本身构建的 Web 应用程序。
目标
本教程讲解如何防护最多见的安全威胁：SQL 注入、操纵 GET 和 POST 变量、缓冲区溢出攻击、跨站点脚本攻击、浏览器内的数据操纵和远程表单提交。
前提条件
本教程是为至少有一年编程经验的 PHP 开发人员编写的。您应该了解 PHP 的语法和约定；这里不解释这些内容。有使用其余语言（好比 Ruby、Python 和 Perl）的经验的开发人员也可以从本教程中受益，由于这里讨论的许多规则也适用于其余语言和环境。
安全性快速简介
Web 应用程序最重要的部分是什么？根据回答问题的人不一样，对这个问题的答案多是五花八门。业务人员须要可靠性和可伸缩性。IT 支持团队须要健壮的可维护的代码。最终用户须要漂亮的用户界面和执行任务时的高性能。可是，若是回答 “安全性”，那么每一个人都会赞成这对 Web 应用程序很重要。
可是，大多数讨论到此就打住了。尽管安全性在项目的检查表中，可是每每到了项目交付以前才开始考虑解决安全性问题。采用这种方式的 Web 应用程序项目的数量多得惊人。开发人员工做几个月，只在最后才添加安全特性，从而让 Web 应用程序可以向公众开放。
结果每每是一片混乱，甚至须要返工，由于代码已经通过检验、单元测试并集成为更大的框架，以后才在其中添加安全特性。添加安全性以后，主要组件可能会中止工做。安全性的集成使得本来顺畅（但不安全）的过程增长额外负担或步骤。
本教程提供一种将安全性集成到 PHP Web 应用程序中的好方法。它讨论几个通常性安全主题，而后深刻讨论主要的安全漏洞以及如何堵住它们。在学完本教程以后，您会对安全性有更好的理解。
主题包括：
SQL 注入攻击
操纵 GET 字符串
缓冲区溢出攻击
跨站点脚本攻击（XSS）
浏览器内的数据操纵
远程表单提交
Web 安全性 101
在讨论实现安全性的细节以前，最好从比较高的角度讨论 Web 应用程序安全性。本节介绍安全哲学的一些基本信条，不管正在建立何种 Web 应用程序，都应该牢记这些信条。这些思想的一部分来自 Chris Shiflett（他关于 PHP 安全性的书是无价的宝库），一些来自 Simson Garfinkel（参见 参考资料），还有一些来自多年积累的知识。
规则 1：毫不要信任外部数据或输入
关于 Web 应用程序安全性，必须认识到的第一件事是不该该信任外部数据。外部数据（outside data） 包括不是由程序员在 PHP 代码中直接输入的任何数据。在采起措施确保安全以前，来自任何其余来源（好比 GET 变量、表单 POST、数据库、配置文件、会话变量或 cookie）的任何数据都是不可信任的。
例如，下面的数据元素能够被认为是安全的，由于它们是在 PHP 中设置的。
清单 1. 安全无暇的代码
[php]$myUsername = ‘tmyer’;
$arrayUsers = array(’tmyer’, ‘tom’, ‘tommy’);
define(”GREETING”, ‘hello there’ . $myUsername); [/php]
可是，下面的数据元素都是有瑕疵的。
清单 2. 不安全、有瑕疵的代码
[php]$myUsername = $_POST['username']; //tainted!
$arrayUsers = array($myUsername, ‘tom’, ‘tommy’); //tainted!
define(”GREETING”, ‘hello there’ . $myUsername); //tainted! [/php]
为何第一个变量 $myUsername 是有瑕疵的？由于它直接来自表单 POST。用户能够在这个输入域中输入任何字符串，包括用来清除文件或运行之前上传的文件的恶意命令。您可能会问，“难道不能使用只接受字母 A-Z 的客户端（JavaScript）表单检验脚原本避免这种危险吗？”是的，这老是一个有好处的步骤，可是正如在后面会看到的，任何人均可以将任何表单下载 到本身的机器上，修改它，而后从新提交他们须要的任何内容。
解决方案很简单：必须对 $_POST['username'] 运行清理代码。若是不这么作，那么在使用 $myUsername 的任何其余时候（好比在数组或常量中），就可能污染这些对象。
对用户输入进行清理的一个简单方法是，使用正则表达式来处理它。在这个示例中，只但愿接受字母。将字符串限制为特定数量的字符，或者要求全部字母都是小写的，这可能也是个好主意。
清单 3. 使用户输入变得安全
[php]$myUsername = cleanInput($_POST['username']); //clean!
$arrayUsers = array($myUsername, ‘tom’, ‘tommy’); //clean!
define(”GREETING”, ‘hello there’ . $myUsername); //clean!
function cleanInput($input){
$clean = strtolower($input);
$clean = preg_replace(”/[^a-z]/”, “”, $clean);
$clean = substr($clean,0,12);
return $clean;
}[/php]
规则 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. 使代码容易获得保护
[php]//obfuscated code
$input = (isset($_POST['username']) ? $_POST['username']:”);
//unobfuscated code
$input = ”;
if (isset($_POST['username'])){
$input = $_POST['username'];
}else{
$input = ”;
}[/php]
在第二个比较清晰的代码段中，很容易看出 $input 是有瑕疵的，须要进行清理，而后才能安全地处理。
规则 4：“纵深防护” 是新的法宝
本教程将用示例来讲明如何保护在线表单，同时在处理表单的 PHP 代码中采用必要的措施。一样，即便使用 PHP regex 来确保 GET 变量彻底是数字的，仍然能够采起措施确保 SQL 查询使用转义的用户输入。
纵深防护不仅是一种好思想，它能够确保您不会陷入严重的麻烦。
既然已经讨论了基本规则，如今就来研究第一种威胁：SQL 注入攻击。
防止 SQL 注入攻击
在 SQL 注入攻击 中，用户经过操纵表单或 GET 查询字符串，将信息添加到数据库查询中。例如，假设有一个简单的登陆数据库。这个数据库中的每一个记录都有一个用户名字段和一个密码字段。构建一个登陆表单，让用户可以登陆。
清单 5. 简单的登陆表单
[php]<html>
<head>
<title>Login</title>
</head>
<body>
<form action=”verify.php” method=”post”>
<p><label for=’user’>Username</label>
<input type=’text’ name=’user’ id=’user’/>
</p>
<p><label for=’pw’>Password</label>
<input type=’password’ name=’pw’ id=’pw’/>
</p>
<p><input type=’submit’ value=’login’/></p>
</form>
</body>
</html>[/php]
这个表单接受用户输入的用户名和密码，并将用户输入提交给名为 verify.php 的文件。在这个文件中，PHP 处理来自登陆表单的数据，以下所示：
清单 6. 不安全的 PHP 表单处理代码
[php]<?php
$okay = 0;
$username = $_POST['user'];
$pw = $_POST['pw'];
$sql = “select count(*) as ctr from users where
username=’”.$username.”‘ and password=’”. $pw.”‘ limit 1″;
$result = mysql_query($sql);
while ($data = mysql_fetch_object($result)){
if ($data->ctr == 1){
//they’re okay to enter the application!
$okay = 1;
}
}
if ($okay){
$_SESSION['loginokay'] = true;
header(”index.php”);
}else{
header(”login.php”);
}
?> [/php]
这段代码看起来没问题，对吗？世界各地成百（甚至成千）的 PHP/MySQL 站点都在使用这样的代码。它错在哪里？好，记住 “不能信任用户输入”。这里没有对来自用户的任何信息进行转义，所以使应用程序容易受到攻击。具体来讲，可能会出现任何类型的 SQL 注入攻击。
例如，若是用户输入 foo 做为用户名，输入 ‘ or ‘1′=’1 做为密码，那么实际上会将如下字符串传递给 PHP，而后将查询传递给 MySQL：
$sql = “select count(*) as ctr from users where
username=’foo’ and password=” or ‘1′=’1′ limit 1″;
这个查询老是返回计数值 1，所以 PHP 会容许进行访问。经过在密码字符串的末尾注入某些恶意 SQL，黑客就能装扮成合法的用户。
解决这个问题的办法是，将 PHP 的内置 mysql_real_escape_string() 函数用做任何用户输入的包装器。这个函数对字符串中的字符进行转义，使字符串不可能传递撇号等特殊字符并让 MySQL 根据特殊字符进行操做。清单 7 展现了带转义处理的代码。
清单 7. 安全的 PHP 表单处理代码
[php]<?php
$okay = 0;
$username = $_POST['user'];
$pw = $_POST['pw'];
$sql = “select count(*) as ctr from users where
username=’”.mysql_real_escape_string($username).”‘
and password=’”. mysql_real_escape_string($pw).”‘ limit 1″;
$result = mysql_query($sql);
while ($data = mysql_fetch_object($result)){
if ($data->ctr == 1){
//they’re okay to enter the application!
$okay = 1;
}
}
if ($okay){
$_SESSION['loginokay'] = true;
header(”index.php”);
}else{
header(”login.php”);
}
?>[/php]
使用 mysql_real_escape_string() 做为用户输入的包装器，就能够避免用户输入中的任何恶意 SQL 注入。若是用户尝试经过 SQL 注入传递畸形的密码，那么会将如下查询传递给数据库：
select count(*) as ctr from users where \
username=’foo’ and password=’\’ or \’1\’=\’1′ limit 1″
数据库中没有任何东西与这样的密码匹配。仅仅采用一个简单的步骤，就堵住了 Web 应用程序中的一个大漏洞。这里得出的经验是，老是应该对 SQL 查询的用户输入进行转义。
可是，还有几个安全漏洞须要堵住。下一项是操纵 GET 变量。
防止用户操纵 变量
在前一节中，防止了用户使用畸形的密码进行登陆。若是您很聪明，应该应用您学到的方法，确保对 SQL 语句的全部用户输入进行转义。
可是，用户如今已经安全地登陆了。用户拥有有效的密码，并不意味着他将按照规则行事 —— 他有不少机会可以形成损害。例如，应用程序可能容许用户查看特殊的内容。全部连接指向 template.php?pid=33 或 template.php?pid=321 这样的位置。URL 中问号后面的部分称为查询字符串。由于查询字符串直接放在 URL 中，因此也称为 GET 查询字符串。
在 PHP 中，若是禁用了 register_globals，那么能够用 $_GET['pid'] 访问这个字符串。在 template.php 页面中，可能会执行与清单 8 类似的操做。
清单 8. 示例 template.php
[php]<?php
$pid = $_GET['pid'];
//we create an object of a fictional class Page
$obj = new Page;
$content = $obj->fetchPage($pid);
//and now we have a bunch of PHP that displays the page
//……
//……
?> [/php]
这里有什么错吗？首先，这里隐含地相信来自浏览器的 GET 变量 pid 是安全的。这会怎么样呢？大多数用户没那么聪明，没法构造出语义攻击。可是，若是他们注意到浏览器的 URL 位置域中的 pid=33，就可能开始捣乱。若是他们输入另外一个数字，那么可能没问题；可是若是输入别的东西，好比输入 SQL 命令或某个文件的名称（好比 /etc/passwd），或者搞别的恶做剧，好比输入长达 3,000 个字符的数值，那么会发生什么呢？
在这种状况下，要记住基本规则，不要信任用户输入。应用程序开发人员知道 template.php 接受的我的标识符（PID）应该是数字，因此可使用 PHP 的 is_numeric() 函数确保不接受非数字的 PID，以下所示：
清单 9. 使用 is_numeric() 来限制 GET 变量
[php]<?php
$pid = $_GET['pid'];
if (is_numeric($pid)){
//we create an object of a fictional class Page
$obj = new Page;
$content = $obj->fetchPage($pid);
//and now we have a bunch of PHP that displays the page
//……
//……
}else{
//didn’t pass the is_numeric() test, do something else!
}?> [/php]
这个方法彷佛是有效的，可是如下这些输入都可以轻松地经过 is_numeric() 的检查：
100 （有效）
100.1 （不该该有小数位）
+0123.45e6 （科学计数法 —— 很差）
0xff33669f （十六进制 —— 危险！危险！）
那么，有安全意识的 PHP 开发人员应该怎么作呢？多年的经验代表，最好的作法是使用正则表达式来确保整个 GET 变量由数字组成，以下所示：
清单 10. 使用正则表达式限制 GET 变量
[php]<?php
$pid = $_GET['pid'];
<b>
if (strlen($pid)){
if (!ereg(”^[0-9]+$”,$pid)){
//do something appropriate, like maybe logging \
them out or sending them back to home page
}
}else{
//empty $pid, so send them back to the home page
}
</b>
//we create an object of a fictional class Page, which is now
//moderately protected from evil user input
$obj = new Page;
$content = $obj->fetchPage($pid);
//and now we have a bunch of PHP that displays the page
//……
//……
?>[/php]
须要作的只是使用 strlen() 检查变量的长度是否非零；若是是，就使用一个全数字正则表达式来确保数据元素是有效的。若是 PID 包含字母、斜线、点号或任何与十六进制类似的内容，那么这个例程捕获它并将页面从用户活动中屏蔽。若是看一下 Page 类幕后的状况，就会看到有安全意识的 PHP 开发人员已经对用户输入 $pid 进行了转义，从而保护了 fetchPage() 方法，以下所示：
清单 11. 对 fetchPage() 方法进行转义
[php]<?php
class Page{
function fetchPage($pid){
$sql = “select pid,title,desc,kw,content,\
status from page where pid=’
”.mysql_real_escape_string($pid).”‘”;
//etc, etc….
}
}
?> [/php]
您可能会问，“既然已经确保 PID 是数字，那么为何还要进行转义？” 由于不知道在多少不一样的上下文和状况中会使用 fetchPage() 方法。必须在调用这个方法的全部地方进行保护，而方法中的转义体现了纵深防护的意义。
若是用户尝试输入很是长的数值，好比长达 1000 个字符，试图发起缓冲区溢出攻击，那么会发生什么呢？下一节更详细地讨论这个问题，可是目前能够添加另外一个检查，确保输入的 PID 具备正确的长度。您知道数据库的 pid 字段的最大长度是 5 位，因此能够添加下面的检查。
清单 12. 使用正则表达式和长度检查来限制 GET 变量
[php]<?php
$pid = $_GET['pid'];
if (strlen($pid)){
if (!ereg(”^[0-9]+$”,$pid) && strlen($pid) > 5){
//do something appropriate, like maybe logging \
them out or sending them back to home page
}
}else{
//empty $pid, so send them back to the home page
}
//we create an object of a fictional class Page, which is now
//even more protected from evil user input
$obj = new Page;
$content = $obj->fetchPage($pid);
//and now we have a bunch of PHP that displays the page
//……
//……
?> [/php]
如今，任何人都没法在数据库应用程序中塞进一个 5,000 位的数值 —— 至少在涉及 GET 字符串的地方不会有这种状况。想像一下黑客在试图突破您的应用程序而遭到挫折时咬牙切齿的样子吧！并且由于关闭了错误报告，黑客更难进行侦察。
缓冲区溢出攻击
缓冲区溢出攻击 试图使 PHP 应用程序中（或者更精确地说，在 Apache 或底层操做系统中）的内存分配缓冲区发生溢出。请记住，您多是使用 PHP 这样的高级语言来编写 Web 应用程序，可是最终仍是要调用 C（在 Apache 的状况下）。与大多数低级语言同样，C 对于内存分配有严格的规则。
缓冲区溢出攻击向缓冲区发送大量数据，使部分数据溢出到相邻的内存缓冲区，从而破坏缓冲区或者重写逻辑。这样就可以形成拒绝服务、破坏数据或者在远程服务器上执行恶意代码。
防止缓冲区溢出攻击的唯一方法是检查全部用户输入的长度。例如，若是有一个表单元素要求输入用户的名字，那么在这个域上添加值为 40 的 maxlength 属性，并在后端使用 substr() 进行检查。清单 13 给出表单和 PHP 代码的简短示例。
清单 13. 检查用户输入的长度
[php]<?php
if ($_POST['submit'] == “go”){
$name = substr($_POST['name'],0,40);
//continue processing….
}
?>
<form action=”<?php echo \
$_SERVER['PHP_SELF'];?>” method=”post”>
<p><label for=”name”>Name</label>
<input type=”text” name=\
“name” id=”name” size=”20″ maxlength=”40″/></p>
<p><input type=”submit” name=”submit” value=”go”/></p>
</form>[/php]
为何既提供 maxlength 属性，又在后端进行 substr() 检查？由于纵深防护老是好的。浏览器防止用户输入 PHP 或 MySQL 不能安全地处理的超长字符串（想像一下有人试图输入长达 1,000 个字符的名称），然后端 PHP 检查会确保没有人远程地或者在浏览器中操纵表单数据。
正如您看到的，这种方式与前一节中使用 strlen() 检查 GET 变量 pid 的长度类似。在这个示例中，忽略长度超过 5 位的任何输入值，可是也能够很容易地将值截短到适当的长度，以下所示：
清单 14. 改变输入的 GET 变量的长度
[php]<?php
$pid = $_GET['pid'];
if (strlen($pid)){
if (!ereg(”^[0-9]+$”,$pid)){
//if non numeric $pid, send them back to home page
}
}else{
//empty $pid, so send them back to the home page
}
//we have a numeric pid, but it may be too long, so let’s check
if (strlen($pid)>5){
$pid = substr($pid,0,5);
}
//we create an object of a fictional class Page, which is now
//even more protected from evil user input
$obj = new Page;
$content = $obj->fetchPage($pid);
//and now we have a bunch of PHP that displays the page
//……
//……
?>[/php]
注意，缓冲区溢出攻击并不限于长的数字串或字母串。也可能会看到长的十六进制字符串（每每看起来像 \xA3 或 \xFF）。记住，任何缓冲区溢出攻击的目的都是淹没特定的缓冲区，并将恶意代码或指令放到下一个缓冲区中，从而破坏数据或执行恶意代码。对付十六进制缓 冲区溢出最简单的方法也是不容许输入超过特定的长度。
若是您处理的是容许在数据库中输入较长条目的表单文本区，那么没法在客户端轻松地限制数据的长度。在数据到达 PHP 以后，可使用正则表达式清除任何像十六进制的字符串。
清单 15. 防止十六进制字符串
[php]<?php
if ($_POST['submit'] == “go”){
$name = substr($_POST['name'],0,40);
//clean out any potential hexadecimal characters
$name = cleanHex($name);
//continue processing….
}
function cleanHex($input){
$clean = preg_replace(”![\][xX]([A-Fa-f0-9]{1,3})!”, “”,$input);
return $clean;
}
?>
<form action=”<?php echo $_SERVER['PHP_SELF'];?>” method=”post”>
<p><label for=”name”>Name</label>
<input type=”text” name=”name” id=”name” size=”20″ maxlength=”40″/></p>
<p><input type=”submit” name=”submit” value=”go”/></p>
</form>[/php]
您可能会发现这一系列操做有点儿太严格了。毕竟，十六进制串有合法的用途，好比输出外语中的字符。如何部署十六进制 regex 由您本身决定。比较好的策略是，只有在一行中包含过多十六进制串时，或者字符串的字符超过特定数量（好比 128 或 255）时，才删除十六进制串。
跨站点脚本攻击
在跨站点脚本（XSS）攻击中，每每有一个恶意用户在表单中（或经过其余用户输入方式）输入信息，这些输入将恶意的客户端标记插入过程或数据库中。例如， 假设站点上有一个简单的来客登记簿程序，让访问者可以留下姓名、电子邮件地址和简短的消息。恶意用户能够利用这个机会插入简短消息以外的东西，好比对于其 他用户不合适的图片或将用户重定向到另外一个站点的 JavaScript，或者窃取 cookie 信息。
幸运的是，PHP 提供了 strip_tags() 函数，这个函数能够清除任何包围在 HTML 标记中的内容。strip_tags() 函数还容许提供容许标记的列表，好比 <b> 或 <i>。
清单 16 给出一个示例，这个示例是在前一个示例的基础上构建的。
清单 16. 从用户输入中清除 HTML 标记
[php]<?php
if ($_POST['submit'] == “go”){
//strip_tags
$name = strip_tags($_POST['name']);
$name = substr($name,0,40);
//clean out any potential hexadecimal characters
$name = cleanHex($name);
//continue processing….
}
function cleanHex($input){
$clean = preg_replace\
(”![\][xX]([A-Fa-f0-9]{1,3})!”, “”,$input);
return $clean;
}
?>
<form action=\
“<?php echo $_SERVER['PHP_SELF'];?>” method=”post”>
<p><label for=”name”>Name</label>
<input type=\
“text” name=”name” id=”name” size=”20″ maxlength=”40″/></p>
<p><input type=”submit” name=”submit” value=”go”/></p>
</form>[/php]
从安全的角度来看，对公共用户输入使用 strip_tags() 是必要的。若是表单在受保护区域（好比内容管理系统）中，并且您相信用户会正确地执行他们的任务（好比为 Web 站点建立 HTML 内容），那么使用 strip_tags() 多是没必要要的，会影响工做效率。
还有一个问题：若是要接受用户输入，好比对贴子的评论或来客登记项，并须要将这个输入向其余用户显示，那么必定要将响应放在 PHP 的 htmlspecialchars() 函数中。这个函数将与符号、< 和 > 符号转换为 HTML 实体。例如，与符号（&）变成 &。这样的话，即便恶意内容躲开了前端 strip_tags() 的处理，也会在后端被 htmlspecialchars() 处理掉。
浏览器内的数据操纵
有一类浏览器插件容许用户篡改页面上的头部元素和表单元素。使用 Tamper Data（一个 Mozilla 插件），能够很容易地操纵包含许多隐藏文本字段的简单表单，从而向 PHP 和 MySQL 发送指令。
用户在点击表单上的 Submit 以前，他能够启动 Tamper Data。在提交表单时，他会看到表单数据字段的列表。Tamper Data 容许用户篡改这些数据，而后浏览器完成表单提交。
让咱们回到前面创建的示例。已经检查了字符串长度、清除了 HTML 标记并删除了十六进制字符。可是，添加了一些隐藏的文本字段，以下所示：
清单 17. 隐藏变量
[php]<?php
if ($_POST['submit'] == “go”){
//strip_tags
$name = strip_tags($_POST['name']);
$name = substr($name,0,40);
//clean out any potential hexadecimal characters
$name = cleanHex($name);
//continue processing….
}
function cleanHex($input){
$clean = \
preg_replace(”![\][xX]([A-Fa-f0-9]{1,3})!”, “”,$input);
return $clean;
}
?>
<form action=\
”<?php echo $_SERVER['PHP_SELF'];?>” method=”post”>
<p><label for=\”name”>Name</label>
<input type=\
“text” name=”name” id=”name” size=”20″ maxlength=”40″/></p>
<input type=”hidden” name=”table” value=”users”/>
<input type=”hidden” name=”action” value=”create”/>
<input type=”hidden” name=”status” value=”live”/>
<p><input type=”submit” name=”submit” value=”go”/></p>
</form>
[/php]
注意，隐藏变量之一暴露了表名：users。还会看到一个值为 create 的 action 字段。只要有基本的 SQL 经验，就可以看出这些命令可能控制着中间件中的一个 SQL 引擎。想搞大破坏的人只需改变表名或提供另外一个选项，好比 delete。
图 1 说明了 Tamper Data 可以提供的破坏范围。注意，Tamper Data 不但容许用户访问表单数据元素，还容许访问 HTTP 头和 cookie。
图 1. Tamper Data 窗口
要防护这种工具，最简单的方法是假设任何用户均可能使用 Tamper Data（或相似的工具）。只提供系统处理表单所需的最少许的信息，并把表单提交给一些专用的逻辑。例如，注册表单应该只提交给注册逻辑。
若是已经创建了一个通用表单处理函数，有许多页面都使用这个通用逻辑，那该怎么办？若是使用隐藏变量来控制流向，那该怎么办？例如，可能在隐藏表单变量中指定写哪一个数据库表或使用哪一个文件存储库。有 4 种选择：
不改变任何东西，暗自祈祷系统上没有任何恶意用户。
重写功能，使用更安全的专用表单处理函数，避免使用隐藏表单变量。
使用 md5() 或其余加密机制对隐藏表单变量中的表名或其余敏感信息进行加密。在 PHP 端不要忘记对它们进行解密。
经过使用缩写或昵称让值的含义模糊，在 PHP 表单处理函数中再对这些值进行转换。例如，若是要引用 users 表，能够用 u 或任意字符串（好比 u8y90×0jkL）来引用它。
后两个选项并不完美，可是与让用户轻松地猜出中间件逻辑或数据模型相比，它们要好得多了。
如今还剩下什么问题呢？远程表单提交。
远程表单提交
Web 的好处是能够分享信息和服务。坏处也是能够分享信息和服务，由于有些人作事毫无顾忌。
以表单为例。任何人都可以访问一个 Web 站点，并使用浏览器上的 File > Save As 创建表单的本地副本。而后，他能够修改 action 参数来指向一个彻底限定的 URL（不指向 formHandler.php，而是指向 http://www.yoursite.com/formHandler.php，由于表单在这个站点上），作他但愿的任何修改，点击 Submit，服务器会把这个表单数据做为合法通讯流接收。
首先可能考虑检查 $_SERVER['HTTP_REFERER']，从而判断请求是否来自本身的服务器，这种方法能够挡住大多数恶意用户，可是挡不住最高明的黑客。这些人足够聪明，可以篡改头部中的引用者信息，使表单的远程副本看起来像是从您的服务器提交的。
处理远程表单提交更好的方式是，根据一个唯一的字符串或时间戳生成一个令牌，并将这个令牌放在会话变量和表单中。提交表单以后，检查两个令牌是否匹配。若是不匹配，就知道有人试图从表单的远程副本发送数据。
要建立随机的令牌，可使用 PHP 内置的 md5()、uniqid() 和 rand() 函数，以下所示：
清单 18. 防护远程表单提交
[php]<?php
session_start();
if ($_POST['submit'] == “go”){
//check token
if ($_POST['token'] == $_SESSION['token']){
//strip_tags
$name = strip_tags($_POST['name']);
$name = substr($name,0,40);
//clean out any potential hexadecimal characters
$name = cleanHex($name);
//continue processing….
}else{
//stop all processing! remote form posting attempt!
}
}
$token = md5(uniqid(rand(), true));
$_SESSION['token']= $token;
function cleanHex($input){
$clean = preg_replace(”![\][xX]([A-Fa-f0-9]{1,3})!”, “”,$input);
return $clean;
}
?>
<form action=”<?php echo $_SERVER['PHP_SELF'];?>” method=”post”>
<p><label for=”name”>Name</label>
<input type=”text” name=”name” id=”name” size=”20″ maxlength=”40″/></p>
<input type=”hidden” name=”token” value=”<?php echo $token;?>”/>
<p><input type=”submit” name=”submit” value=”go”/></p>
</form>
[/php]
这种技术是有效的，这是由于在 PHP 中会话数据没法在服务器之间迁移。即便有人得到了您的 PHP 源代码，将它转移到本身的服务器上，并向您的服务器提交信息，您的服务器接收的也只是空的或畸形的会话令牌和原来提供的表单令牌。它们不匹配，远程表单提交就失败了。
结束语
本教程讨论了许多问题：
使用 mysql_real_escape_string() 防止 SQL 注入问题。
使用正则表达式和 strlen() 来确保 GET 数据未被篡改。
使用正则表达式和 strlen() 来确保用户提交的数据不会使内存缓冲区溢出。
使用 strip_tags() 和 htmlspecialchars() 防止用户提交可能有害的 HTML 标记。
避免系统被 Tamper Data 这样的工具突破。
使用唯一的令牌防止用户向服务器远程提交表单。
本教程没有涉及更高级的主题，好比文件注入、HTTP 头欺骗和其余漏洞。可是，您学到的知识能够帮助您立刻增长足够的安全性，使当前项目更安全。php
原文地址：http://bbs.phpchina.com/thread-105020-1-1.htmlhtml