PHP与SQL注入攻击

SQL注入攻击是黑客攻击网站最常用的手段。假如你的站点没有使用严格的用户输入检验，那么常轻易遭到SQL注入攻击。SQL注入攻击通常通过给站点数据库提交不良的数据或查询语句来实现，很可能使数据库中的纪录遭到暴露，更改或被删除。下面来谈谈SQL注入攻击是如何实现的，又如何防范。

　　看这个例子：

// supposed input
$name = "ilia'; DELETE FROM users;";
mysql_query("SELECT * FROM users WHERE name='{$name}'");


　　很明显最后数据库执行的命令是：

SELECT * FROM users WHERE name=ilia; DELETE FROM users


　　这就给数据库带来了灾难性的后果--所有记录都被删除了。

　　不过假如你使用的数据库是MySQL，那么还好，mysql_query()函数不答应直接执行这样的操作（不能单行进行多个语句操作），所以你可以放心。假如你使用的数据库是SQLite或者PostgreSQL，支持这样的语句，那么就将面临灭顶之灾了。

　　上面提到，SQL注入主要是提交不安全的数据给数据库来达到攻击目的。为了防止SQL注入攻击，PHP自带一个功能可以对输入的字符串进行处理，可以在较底层对输入进行安全上的初步处理，也即Magic Quotes。(php.ini magic_quotes_gpc)。假如magic_quotes_gpc选项启用，那么输入的字符串中的单引号，双引号和其它一些字符前将会被自动加上反斜杠。

　　但Magic Quotes并不是一个很通用的解决方案，没能屏蔽所有有潜在危险的字符，并且在许多服务器上Magic Quotes并没有被启用。所以，我们还需要使用其它多种方法来防止SQL注入。

　　许多数据库本身就提供这种输入数据处理功能。例如PHP的MySQL操作函数中有一个叫mysql_real_escape_string()的函数，可将非凡字符和可能引起数据库操作出错的字符转义。

　　看这段代码：

//假如Magic Quotes功用启用
if (get_magic_quotes_gpc()) {
$name = stripslashes($name);
}else{
$name = mysql_real_escape_string($name);
}

mysql_query("SELECT * FROM users WHERE name='{$name}'");

　　注重，在我们使用数据库所带的功能之前要判定一下Magic Quotes是否打开，就像上例中那样，否则两次重复处理就会出错。假如MQ已启用，我们要把加上的去掉才得到真实数据。

　　除了对以上字符串形式的数据进行预处理之外，储存Binary数据到数据库中时，也要注重进行预处理。否则数据可能与数据库自身的存储格式相冲突，引起数据库崩溃，数据记录丢失，甚至丢失整个库的数据。有些数据库如PostgreSQL，提供一个专门用来编码二进制数据的函数pg_escape_bytea()，它可以对数据进行类似于Base64那样的编码。

　　如：

// for plain-text data use:
pg_escape_string($regular_strings);

// for binary data use:
pg_escape_bytea($binary_data);

　　另一种情况下，我们也要采用这样的机制。那就是数据库系统本身不支持的多字节语言如中文，日语等。其中有些的ASCII范围和二进制数据的范围重叠。

　　不过对数据进行编码将有可能导致像LIKE abc%　这样的查询语句失效。

对于脚本安全这个话题似乎永远没完没了，假如你经常到国外的各种各样的bugtraq上，你会发现有一半以上都和脚本相关,诸如SQL injection,XSS,Path Disclosure,Remote commands execution这样的字眼比比皆是，我们看了之后的用途难道仅仅是抓肉鸡？对于我们想做web安全的人来说，最好就是拿来学习，可是万物抓根源，我们要的不是鱼而是渔。在国内，各种各样的php程序1.0版,2.0版像雨后春笋一样的冒出来，可是，大家关注的都是一些闻名的cms,论坛,blog程序，很少的人在对那些不出名的程序做安全检测，对于越来越多的php程序员和站长来说，除了依靠服务器的堡垒设置外，php程序本身的安全多少你总得懂点吧。

有人说你们做php安全无非就是搞搞注入和跨站什么什么的，大错特错，假如这样的话，一个magic_quotes_gpc或者服务器里的一些安全设置就让我们全没活路了：（。我今天要说的不是注入，不是跨站，而是存在于php程序中的一些安全细节问题。OK!切入正题。

注重一些函数的过滤

有些函数在程序中是经常使用的,像include(),require(),fopen(),fwrite(),readfile(),unlink(),eval()以及它们的变体函数等等。这些函数都很实用，实用并不代表让你多省心，你还得为它们多费点心。 ：）

1.include(),require()和fopen(),include_once(),require_once()这些都可以远程调用文件，对于它们的危害，google搜一下你就会很明了，对于所包含调用的变量没过滤好，就可以任意包含文件从而去执行。举个例子，看print.php

...

if (empty ($bn) ) { //检查是变量$bn是否为空

include ("$cfg_dir/site_${site}.php"); //把$cfg_dir这个路径里的site_${site}.php包含进来

...

不管存不存在$cfg_dir目录，$site这个变量你可以很自然的去使用，因为他根本没检查$site变量啊。可以把变量$site指定远程文件去调用，也可以是本地的一个文件，你所指定的文件里写上php的语句，然后它就去包含执行这个含有php语句的文件了.就像这样

列出文件目录

甚至可以扩展到包含一些治理员文件，提升权限，典型的像以前phpwind,bo-blog的漏洞一样。除了依靠php.ini里的allow_url_fopen设为off禁止远程使用文件和open_base_dir禁止使用目录以外的文件外，你还得事先声明好只能包含哪些文件，这里就不多说废话了。

2.fopen(),file(),readfile(),openfile(),等也是该非凡留意的地方。函数本身并没什么,它们的作用是去打开文件，可是假如对变量过滤不彻底的话，就会泄露源代码。这样的函数文本论坛里会有很多。

...

$articlearray=openfile("$dbpath/$fid/$tid.php"); //打开$dbpath/$fid这个路径的$tid.php文件

$topic_detail=explode("|",$articlearray[0]); //用分割符|读出帖子的内容

...

很眼熟吧，这是ofstar以前版本的read.php,$fid和$tid没有任何过滤，$tid指定为某个文件提交，就发生了原代码泄露。就像这样。

http://explame.com/ofstar/read.php?fid=123&tid=../index

$tid会被加上php的后缀，所以直接写index。这仅仅是个例子，接着看吧。

3.fwrite()和它的变体函数这种漏洞想想都想得出，对于用户提交的字符没过滤的话，写入一段php后门又不是不可以。

4.unlink()函数，前段时间，phpwind里任意删除文件就是利用这个函数，对于判定是否删除的变量没过滤，变量可以指定为任意文件，当然就可以删除任意文件的变量。

5.eval(),preg_replace()函数，它们的作用是执行php代码，假如字符串没被经过任何过滤的话，会发生什么呢，我就常看见一些cms里面使用，想想，一句话的php木马不就是根据eval()原理制作的吗？

6.对于system()这些系统函数，你会说在php.ini里禁止系统函数，对，这也是好办法，可是象一些程序里需要，那是不是就不用了呢？就像上次我看到的一套很漂亮的php相册一样。另外对于popen(),proc_open(),proc_close()函数你也得非凡注重，尽管他们执行命令后并没有直接的输出，但你想这到底对黑客们有没有用呢。再这里php提供提供了两个函数，escapeshellarg(),escapeshellcmd(),这两个函数用来对抗系统函数的调用攻击，也就是过滤。

对于危害，来举个例子，我们来看某论坛prod.php

07 $doubleApp = isset($argv[1]); //初始化变量$doubleApp

...

14 if( $doubleApp ) //if语句

15 {

16 $appDir = $argv[1]; //初始化$appDir

17 system("mkdir $prodDir/$appDir"); //使用系统函数system来创建目录$prodDir/$appDir

本来是拿来创建$prodDir/$appDir目录的，再接着看上去，程序仅仅检测是否存在$argv[1]，缺少对$argv[1]的必要过滤，那么你就可以这样

/prod.php?argv[1]=|ls -la或者/prod.php?argv[1]=|cat /etc/passwd

（分割符 | 在这里是UNIX的管道参数，可以执行多条命令。）

到这里，常见的漏洞类型应该知道点了吧。

对于非凡字符的重视

对于非凡字符，有句话叫All puts is invalid.外国人文章里这句话很常见的。所有输入都是有害的。你永远不要对用户所输入的东西省心，为了对付这些危害，程序员都在忙着过滤大把大把的字符，唯恐漏了什么。而有些程序员呢？似乎从没注重过这些问题，从来都是敞开漏洞大门的。不说废话，还是先看看下面这些东西吧。

1.其实程序的漏洞里最要害，最让开发者放心不下的就是带着$符号的美元符号，变量，对于找漏洞的人来说，抓着变量两个字就是一切。就像目录遍历这个bug，很多邮件程序都存在，开发者考虑的很周全，有的甚至加上了网络硬盘这个东西，好是好，就像

http://mail.com/file.php?id=1&put=list&tid=1&file=./

要是我们把file这个变量换成./../甚至更上层呢？目录就这样被遍历了。

2.尖括号"<>"跨站你不会不知道吧，一些搜索栏里，文章，留言，像前段时间phpwind附件那里的跨站等等。当然，对于跨站问题，你要过滤的远远不止尖括号。不怕过滤时漏掉什么，而是怕你想不起要去过滤。

3.斜杆和反斜杆：对于/和的过滤，记得魔力论坛的附件下载处的原代码泄露吗？

attachment.php?id=684&u=3096&extension=gif&attach=.............includesconfig.php&filename=1.gif

对于过滤.. / 的问题，像windows主机不仅要过滤../还要过滤..,windows主机对会解析为/,这些细节跟SQL injection比起来，什么才叫深入呢？

4.对于反引号(``),反引号在php中很强大，它可以执行系统命令，就像system()这些系统函数一样，假如用户的恶意语句被它所执行的话就会危害服务器，我想除了服务器设置的很好以外，对于它们，你还是老老实实的过滤好吧。

5.对于换行符,NULL字符等等，像" ,x0B, , ,

以下 $username, $password 分别指用户名和密码，$sitekey 为站点扰码。

　　密码设置

<input type="password" name="passwd" />
<input type="hidden" name="t_code0" />

　　提交的时候，使用 javascript 处理


t_code0.value = md5 (username.value "|" passwd.value);
passwd.value = '';

　　假如提交的 passwd 有值或 t_code0 为空，设置密码失败；

　　t_code0 的值保存到数据库的 save_pwd 字段中；


　　密码校验

　　1. 用户端申请登录
　　服务器生成随机码 $sid，保存到 $_SESSION[sid] 中，同时传递给用户；

　　表单


<input type="hidden" name="sid" value="..." />
<input name="username" />
<input type="password" name="passwd" />
<input type="hidden" name="t_code" />

　　2. 用户输入用户名和密码，提交的时候，使用 javascript 处理


var t = md5 (username.value "|" passwd.value);
t_code.value = md5 (sid "|" t);
passwd.value = '';
　　3. 服务器端判定
　　假如 username 为空 或 passwd 非空 或 t_code 为空，返回登录页；
　　如没有 $_SESSION[sid]，返回登录页；


[php]

<?php
/*
*lock_thisfile：获得独享锁
*@param $tmpFileStr 用来作为共享锁文件的文件名（可以随便起一个名字）
*@param $locktype 锁类型，缺省为false(非阻塞型，也就是一旦加锁失败则直接返回false),设置为true则会一直等待加锁成功才返回
*@return 假如加锁成功，则返回锁实例(当使用unlock_thisfile方法的时候需要这个参数)，加锁失败则返回false.
*/
function lock_thisfile($tmpFileStr,$locktype=false){
if($locktype == false)
$locktype = LOCK_EX|LOCK_NB;
$can_write = 0;
$lockfp = @fopen($tmpFileStr.".lock","w");
if($lockfp){
$can_write = @flock($lockfp,$locktype);
}
if($can_write){
return $lockfp;
}
else{
if($lockfp){
@fclose($lockfp);
@unlink($tmpFileStr.".lock");
}
return false;
}
}

/**
*unlock_thisfile：对先前取得的锁实例进行解锁
*@param $fp lock_thisfile方法的返回值
*@param $tmpFileStr 用来作为共享锁文件的文件名（可以随便起一个名字）
*/
function unlock_thisfile($fp,$tmpFileStr){
@flock($fp,LOCK_UN);
@fclose($fp);
@fclose($fp);
@unlink($tmpFileStr.".lock");
}
?>

<?php
// 使用举例
$tmpFileStr = "/tmp/mylock.loc";

// 等待取得操作权限,假如要立即返回则把第二个参数设为false.
$lockhandle = lock_thisfile($tmpFileStr,true);
if($lockhandle){
// 在这里进行所有需要独占的事务处理。
// ... ...
// 事务处理完毕。
unlock_thisfile($lockhandle,$tmpFileStr);
}

?>

　假如你希望在每个脚本的基础上实现口令保护功能，那么你可以通过结合header()函数和$PHP_AUTH_USER、$PHP_AUTH_PW全局变量的方法来创建一个基本认证机制。通常基于服务器的认证请求/响应过程如下：

　　1. 用户向一台Web服务器请求一个文件。假如文件在一个受到保护的区域以内，服务器就在响应数据的头部内加上401（非法用户）字符串作为回应。

　　2.浏览器看见该响应之后弹出用户名/口令对话框。

　　3.用户在对话框中输入用户名和口令，然后单击“OK”把这些信息送回到服务器进行认证。

　　4. 如用户名及口令有效，被保护的文件将会显示给用户。该确认将在经证实的用户在保护区域内的时间里持续有效。　

　　一个简单的PHP脚本可以通过发送适当的HTTP头以在客户机屏幕自动显示用户名/口令对话框以模拟HTTP认证请求/响应系统。PHP将用户输入对话框的信息存储在$PHP_AUTH_USER和$PHP_AUTH_PW变量中。通过使用这些变量，可以把不符合用户名/口令检验的列表存放到某个文本文件、数据库或者你希望的任何地方。

　　注重：$PHP_AUTH_USER、$PHP_AUTH_PW和$PHP_AUTH_TYPE全局变量仅当PHP被当作一个模块安装时才是有效的。如正使用PHP的CGI版本，则将仅限于使用基于htaccess认证或基于数据库的认证方式，并通过HTML表单让用户输入用户名和口令，然后再让PHP完成有效性的检查。

　　本例显示对两个硬件编码值的确认检查，不论用户名和口令存放在何处，这在理论上完全相同。

<?

/* 检查变量 $PHP_AUTH_USER 和$PHP_AUTH_PW 的值*/

if ((!isset($PHP_AUTH_USER)) || (!isset($PHP_AUTH_PW))) {

/* 空值：发送产生显示文本框的数据头部*/

header('WWW-Authenticate: Basic realm="My Private Stuff"');

header('HTTP/1.0 401 Unauthorized');

echo 'Authorization Required.';

exit;

} else if ((isset($PHP_AUTH_USER)) && (isset($PHP_AUTH_PW))){

/* 变量值存在，检查其是否正确 */

if (($PHP_AUTH_USER != "validname") || ($PHP_AUTH_PW != "goodpassword")) {

/* 用户名输入错误或密码输入错误，发送产生显示文本框的数据头部*/

header('WWW-Authenticate: Basic realm="My Private Stuff"');

header('HTTP/1.0 401 Unauthorized');

echo 'Authorization Required.';

exit;

} else if (($PHP_AUTH_USER == "validname") || ($PHP_AUTH_PW == "goodpassword")) {

/* 用户名及密码都正确，输出成功信息 */

echo "<P>You're authorized!</p>";

}

}

?>

必须提醒，当你正在使用基于文件的保护时，此方式并不能对目录提供全方位的安全保障。。这对大多数人而言是很明显的，但是，假如你的大脑在弹出对话框和保护给定目录二者之间建立一个连接，你应该对此进行进一步的考虑。