php过滤提交数据 防止sql注入攻击.docx

php过滤提交数据 防止sql注入攻击.docx

《php过滤提交数据 防止sql注入攻击.docx》由会员分享，可在线阅读，更多相关《php过滤提交数据 防止sql注入攻击.docx（13页珍藏版）》请在冰豆网上搜索。

php过滤提交数据防止sql注入攻击

php过滤提交数据防止sql注入攻击

在SQL注入攻击中，用户通过操纵表单或GET查询字符串，将信息添加到数据库查询中。

例如，假设有一个简单的登录数据库。

这个数据库中的每个记录都有一个用户名字段和一个密码字段。

构建一个登录表单，让用户能够登录。

规则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的客户端（Javascrīpt）表单检验脚本来避免这种危险吗?

”是的，这总是一个有好处的步骤，但是正如在后面会看到的，任何人都可以将任何表单下载到自己的机器上，修改它，然后重新提交他们需要的任何内容。

解决方案很简单：

必须对$_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变量。

规则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）攻击中，往往有一个恶意用户在表单中（或通过其他用户输入方式）输入信息，这些输入将恶意的客户端标记插入过程或数据库中。

例如，假设站点上有一个简单的来客登记簿程序，让访问者能够留下姓名、电子邮件地址和简短的消息。

恶意用户可以利用这个机会插入简短消息之外的东西，比如对于其他用户不合适的图片或将用户重定向到另一个站点的Javascrīpt，或者窃取cookie信息。

幸运的是，PHP提供了strip_tags（）函数，这个函数可以清除任何包围在HTML标记中的内容。

strip_tags（）函数还允许提供允许标记的列表，比如或。

浏览器内的数据操纵

有一类浏览器插件允许用户篡改页面上的头部元素和表单元素。

使用TamperData（一个Mozilla插件），可以很容易地操纵包含许多隐藏文本字段的简单表单，从而向PHP和MySQL发送指令。

用户在点击表单上的Submit之前，他可以启动TamperData。

在提交表单时，他会看到表单数据字段的列表。

TamperData允许用户篡改这些数据，然后浏览器完成表单提交。