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

条件条件

本教程是为至少有一年编程履历的 PHP 开拓职员编写的。
您该当理解 PHP 的语法和约定;这里不阐明这些内容。
有利用其他措辞(比如 Ruby、Python 和 Perl)的履历的开拓职员也能够从本教程中受益,由于这里谈论的许多规则也适用于其他措辞和环境。

php代码安全谈谈关于PHP的代码平安相干的一些致命常识 Vue.js

安全性快速简介

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. 安全无暇的代码

$myUsername = ‘tmyer’;

$arrayUsers =array(’tmyer’, ‘tom’, ‘tommy’);

define(”GREETING”, ‘hello there’ .$myUsername);

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

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

$myUsername =$_POST['username'];//tainted!

$arrayUsers =array($myUsername, ‘tom’, ‘tommy’);//tainted!

define(”GREETING”, ‘hello there’ .$myUsername);//tainted!

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

办理方案很大略:必须对 $_POST['username'] 运行清理代码。
如果不这么做,那么在利用 $myUsername 的任何其他时候(比如在数组或常量中),就可能污染这些工具。

对用户输入进行清理的一个大略方法是,利用正则表达式来处理它。
在这个示例中,只希望接管字母。
将字符串限定为特天命量的字符,或者哀求所有字母都是小写的,这可能也是个好主张。

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

$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;

}

规则 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. 使代码随意马虎得到保护

//obfuscated code

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

//unobfuscated code

$input = ”;

if (isset($_POST['username'])){

$input =$_POST['username'];

}else{

$input = ”;

}

在第二个比较清晰的代码段中,很随意马虎看出 $input 是有瑕疵的,须要进行清理,然后才能安全地处理。

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

本教程将用示例来解释如何保护在线表单,同时在处理表单的 PHP 代码中采取必要的方法。
同样,纵然利用 PHP regex 来确保 GET 变量完备是数字的,仍旧可以采纳方法确保 SQL 查询利用转义的用户输入。

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

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

防止 SQL 注入攻击

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

清单 5. 大略的登录表单

Login

Username

Password

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

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

$okay = 0;

$username =$_POST['user'];

$pw =$_POST['pw'];

$sql = “selectcount()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/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 表单处理代码

$okay = 0;

$username =$_POST['user'];

$pw =$_POST['pw'];

$sql = “selectcount()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”);

}

利用 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

$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

//……

//……

这里有什么错吗?首先,这里隐含地相信来自浏览器的 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)){

//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!

}

这个方法彷佛是有效的,但是以下这些输入都能够轻松地通过 is_numeric() 的检讨:

100 (有效)

100.1 (不应该有小数位)

+0123.45e6 (科学计数法 —— 不好)

0xff33669f (十六进制 —— 危险!
危险!

那么,有安全意识的 PHP 开拓职员该当怎么做呢?多年的履历表明,最好的做法是利用正则表达式来确保全体 GET 变量由数字组成,如下所示:

清单 10. 利用正则表达式限定 GET 变量

$pid =$_GET['pid'];

if (strlen($pid)){

if (!ereg(”^[0-9]+$”,$pid)){

//do something appropriate, like maybe logging \

them outor 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

//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

//……

//……

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

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

class Page{

function fetchPage($pid){

$sql = “select pid,title,desc,kw,content,\

status from page where pid=’

”.mysql_real_escape_string($pid).”‘”;

//etc, etc….

}

}

您可能会问,“既然已经确保 PID 是数字,那么为什么还要进行转义?” 由于不知道在多少不同的高下文和情形中会利用 fetchPage() 方法。
必须在调用这个方法的所有地方进行保护,而方法中的转义表示了纵深防御的意义。

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

清单 12. 利用正则表达式和长度检讨来限定 GET 变量

$pid =$_GET['pid'];

if (strlen($pid)){

if (!ereg(”^[0-9]+$”,$pid) &&strlen($pid) > 5){

//do something appropriate, like maybe logging \

them outor 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

//……

//……

现在,任何人都无法在数据库运用程序中塞进一个 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);

//continue processing….

}

;

Name

“name” id=”name” size=”20″ maxlength=”40″/>

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

正如您看到的,这种办法与前一节中利用 strlen() 检讨 GET 变量 pid 的长度相似。
在这个示例中,忽略长度超过 5 位的任何输入值,但是也可以很随意马虎地将值截短到适当的长度,如下所示:

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

$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

//……

//……

把稳,缓冲区溢出攻击并不限于长的数字串或字母串。
也可能会看到长的十六进制字符串(每每看起来像 \xA3 或 \xFF)。
记住,任何缓冲区溢出攻击的目的都是淹没特定的缓冲区,并将恶意代码或指令放到下一个缓冲区中,从而毁坏数据或实行恶意代码。
对付十六进制缓冲区溢出最大略的方法也是不许可输入超过特定的长度。

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

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

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;

}

” 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);

//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;

}

“” method=”post”

Name

“text” name=”name” id=”name” size=”20″ maxlength=”40″/>

从安全的角度来看,对公共用户输入利用 strip_tags() 是必要的。
如果表单在受保护区域(比如内容管理系统)中,而且您相信用户会精确地实行他们的任务(比如为 Web 站点创建 HTML 内容),那么利用 strip_tags() 可能是不必要的,会影响事情效率。

还有一个问题:如果要接管用户输入,比如对贴子的评论或来客登记项,并须要将这个输入向其他用户显示,那么一定要将相应放在 PHP 的 htmlspecialchars() 函数中。
这个函数将与符号、< 和 > 符号转换为 HTML 实体。
例如,与符号(&)变成 &。
这样的话,纵然恶意内容躲开了前端 strip_tags() 的处理,也会在后端被 htmlspecialchars() 处理掉。

浏览器内的数据操纵

有一类浏览器插件许可用户修改页面上的头部元素和表单元素。
利用 Tamper Data(一个 Mozilla 插件),可以很随意马虎地操纵包含许多隐蔽文本字段的大略表单,从而向 PHP 和 MySQL 发送指令。

用户在点击表单上的 Submit 之前,他可以启动 Tamper Data。
在提交表单时,他会看到表单数据字段的列表。
Tamper Data 许可用户修改这些数据,然后浏览器完成表单提交。

让我们回到前面建立的示例。
已经检讨了字符串长度、打消了 HTML 标记并删除了十六进制字符。
但是,添加了一些隐蔽的文本字段,如下所示:

清单 17. 隐蔽变量

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;

}

”” method=”post”

Name

“text” name=”name” id=”name” size=”20″ maxlength=”40″/>

把稳,隐蔽变量之一暴露了表名:users。
还会看到一个值为 create 的 action 字段。
只要有基本的 SQL 履历,就能够看出这些命令可能掌握着中间件中的一个 SQL 引擎。
想搞大毁坏的人只需改变表名或供应另一个选项,比如 delete。

图 1 解释了 Tamper Data 能够供应的毁坏范围。
把稳,Tamper Data 不但许可用户访问表单数据元素,还许可访问 HTTP 头和 cookie。

要防御这种工具,最大略的方法是假设任何用户都可能利用 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. 防御远程表单提交

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;

}

” method=”post”

Name

这种技能是有效的,这是由于在 PHP 中会话数据无法在做事器之间迁移。
纵然有人得到了您的 PHP 源代码,将它转移到自己的做事器上,并向您的做事器提交信息,您的做事器吸收的也只是空的或畸形的会话令牌和原来供应的表单令牌。
它们不匹配,远程表单提交就失落败了。

结束语

本教程谈论了许多问题:

利用 mysql_real_escape_string() 防止 SQL 注入问题。

利用正则表达式和 strlen() 来确保 GET 数据未被修改。

利用正则表达式和 strlen() 来确保用户提交的数据不会使内存缓冲区溢出。

利用 strip_tags() 和 htmlspecialchars() 防止用户提交可能有害的 HTML 标记。

避免系统被 Tamper Data 这样的工具打破。

利用惟一的令牌防止用户向做事器远程提交表单。

本教程没有涉及更高等的主题,比如文件注入、HTTP 头欺骗和其他漏洞。
但是,您学到的知识可以帮助您立时增加足够的安全性,使当前项目更安全。

作者:php_bruce

链接:https://www.jianshu.com/p/f8bfccb1dfc0