4   变量感染

    这个很容易理解，当一个变量不安全的时候，与之有关的赋值等操作都是不安全的，譬如：

$id = $_GET[id];
...........
$articleid = $id;

实际过程中可能没有这么明显，但是结果是一样的，只要某个变量把敏感字符带入不该带的地方，那么就会产生威胁，不只是变量，不安全的函数会让使用这个函数的所有代码都变的不安全。

二  哪里是不安全的

    变量最终是要代码处理的，代码最终是要依靠一些系统的函数和语句执行的，不正确的变量出现在危险的函数里，那么恭喜你，漏洞出现了！

1   Sql注射漏洞：按照我们的理解，就是Sql函数里出现了不安全的变量，在php中执行这样的语句在系统中是很多的，在Dz的初始化文件中有如下代码：

if($sid) {
        if($discuz_uid) {
                $query = $db->query("SELECT s.sid, s.styleid, s.groupid='6' AS ipbanned, s.pageviews AS spageviews, s.lastolupdate, s.seccode, m.uid AS discuz_uid,
                        m.username AS discuz_user, m.password AS discuz_pw, m.secques AS discuz_secques, m.adminid, m.groupid, m.groupexpiry,
                        m.extgroupids, m.email, m.timeoffset, m.tpp, m.ppp, m.posts, m.digestposts, m.oltime, m.pageviews, m.credits, m.extcredits1, m.extcredits2, m.extcredits3,
                        m.extcredits4, m.extcredits5, m.extcredits6, m.extcredits7, m.extcredits8, m.timeformat, m.dateformat, m.pmsound,
                        m.sigstatus, m.invisible, m.lastvisit, m.lastactivity, m.lastpost, m.newpm, m.accessmasks,m.xspacestatus, m.editormode, m.customshow
                        FROM {$tablepre}sessions s, {$tablepre}members m
                        WHERE m.uid=s.uid AND s.sid='$sid' AND CONCAT_WS('.',s.ip1,s.ip2,s.ip3,s.ip4)='$onlineip' AND m.uid='$discuz_uid'
                        AND m.password='$discuz_pw' AND m.secques='$discuz_secques'");
        } else {
                $query = $db->query("SELECT sid, uid AS sessionuid, groupid, groupid='6' AS ipbanned, pageviews AS spageviews, styleid, lastolupdate, seccode
                        FROM {$tablepre}sessions WHERE sid='$sid' AND CONCAT_WS('.',ip1,ip2,ip3,ip4)='$onlineip'");

找下$db->query函数中的美圆符号吧，呵呵，发现有好几个，也就是说可能存在漏洞了，注意，说的是可能，因为现在的代码安全性都有提高，找个没人管的变量不容易啊，一般的变量都会正确的初试化，但是跟踪$onlineip变量就可以发现这个变量基本没有管的，因为这个是从Http头里提取的，一般的人不怎么会注意这个，但是偏偏问题出现了:）
    需要说明的是，函数产生漏洞，而不管语句是什么，所以只要是update或者insert或者是select里出现了变量，该变量是我们可以控制的，并且改变量能突破程序的一些限制（什么限制我们后面会讲到）从而控制这个sql语句的执行，那么我们的漏洞就是成立的，能不能利用就要看具体环境了

2    Xss跨站脚本攻击漏洞：这个漏洞其根本就是客户端的Html注射漏洞，如果用户提交变量里含有<>或者能被解释成Html的字符被送到数据库，然后再从数据库输出到浏览者的浏览器，那么就可能存在Xss注射漏洞。<>字符能导致跨站脚本攻击很好理解，但是要注意的是不需要提交<>一样会有这种问题，这是很多人所误解的。假设我们的输入如一个url最终是放在一个Html标签之内的，这样的情况很多，因为用户的头像什么的就必须这样的形式：

echo "<img src=\"$url\">"

我们控制了img的属性从也一样实现了跨站脚本攻击。

3   文件包含漏洞：这个主要是因为文件包含函数include与require等函数的参数中没有做好限制，导致用户能指定需要包含的文件如如下的代码：

require_once ROOT_PATH."cache/style/$cssname.php";

如果我们能控制$cssname就可以控制需要包含的内容，漏洞的存在就取决于这个变量可不可以控制了，如果可以控制又可以用到../跳转的话，那么......：）至于危害，也就是任意代码执行和目录遍历了。

4   直接写入webshell漏洞：这在一些文本数据库中见的很多，一些程序使用文本文件做为数据库，于是不可避免的要用到如fopen，fread以及fwrite这些函数，打开fopen函数的帮助看看：

resource fopen ( string filename, string mode [, bool use_include_path [, resource zcontext]] )

从这个帮助可以知道如果fopen函数的第一个参数可以控制就可能打开一些不应该被打开的文件，其他的文件函数都是例似的，再次重申，变量的环境决定了它的价值：）

5  代码执行漏洞：能产生这种漏洞的一定要有这种功能的函数，常见的有eval函数和preg_replace函数，如果eval里出现了我们能控制的语句那么会产生问题，在preg_replace函数的第二个参数可能导致任意代码执行的问题！

6  绝对路径泄露：这主要是由于php的报错造成的，使用一个不存在的文件，mysql查询出错，提交一个不符合类型的参数给一些函数都会导致这个问题，一般的程序都对函数的错误用了@抑制，但是还是存在一些爆路径的方法！有人说一个路径不能代表什么，其实一个路径可以知道操作系统，知道路径，可能知道虚拟主机的配置等等信息。、

7  逻辑混乱：如果一个变量用在了if等逻辑语句中，那么很可能导致逻辑混乱问题，跳过一些语句的执行等等。

......种种其他的函数出现的问题

三  过滤与饶过过滤

    很多人已经注意到了这些安全问题，php中也包含了自己的安全机制，那就是GPC=On的时候加入了对'和"以及\的转义，很多的程序也都自己加入了这些转义。其他脚本语言可能没有这种机制，但是这种思路非常好。在被转义的情况下，他可以保证用户所有的输入都是字符串，无论这个变量进入哪里，包括sql查询，跨站脚本等等，但是有个很重要的前提就是你所书写的程序必须也把所有的输入都当作字符串来对待。很明显，如果有以下的2个语句：

$query = $db->query("select * from user where uid=$id");
$query = $db->query("select * from user where uid='$id'");

哪个更安全一点呢？第一个语句做的假设是$id是数字类型变量，第二个假设输入是字符类型变量所以使用''引用他。如果提交php?id=1 and 1=2对于第一个语句，最后变成：

select * from user where uid=1 and 1=2   //and 1=2成为了一个表达式
select * from user where uid='1 and 1=2' //and 1=2还是字符串的一部分

希望这个能给你一点提示，但不仅仅是sql注入！如果是跨站脚本漏洞的话，我们一样可以使用上面的思路，无论用户输入什么，在过滤好<>，然后只要把用户的输入当作一个字符串就行了，但是要注意，光一个转义字符\'在html里很可能还是有'的意义，你需要去掉他在html里的转义，用htmlspecialchars()函数，当然也要配合程序安全的代码，还是给两个例子：

echo "<img src=htmlspecialchars($url)>";
echo "<img src='htmlspecialchars($url)'>";

哪个是没有缺陷的呢？
    上面的例子是在暗示，一个变量如果只能作为字符串，就是不要赋予它特定的含义，它是做不了什么的。那么你可能已经想到了，对于上面提到的种种漏洞，如果迫不得已需要用户控制变量，那么你只要过滤掉特殊意义的字符，然后把输入只是作为一个字符串，那么就可以从代码级别上杜绝这些漏洞了。譬如对于fopen函数，只要我们过滤掉../以及..\这些字符，然后将用户输入的"，'以及空字符等转义就没有问题了，对于写webshell的问题可以通过如果是建立数据库而已就可以转义掉<>脚本标记字符，如果产生的本身就是php文件那么可以将用户的输入限制在''或者在""之内，一切只是字符 ，跟跨站脚本的防御很相似吧！还有一些敏感字符可能是程序自己产生的，如下的代码：

$deldb=explode("|",$imgdb['icon']);

就赋予了$imgdb['icon']神圣的意义，所以我们在处理的时候一定先要将 $imgdb['icon'] 里的|清干净！

四  其他的问题

    我上面所说的仅仅是在检测漏洞与修补漏洞时的一些想法， 从函数着手分析变量的处理，但更多的时候程序的安全还是要依靠程序员清晰的思路的，但安全不仅仅是这样，譬如GBK和Big5的编码问题，还有上传等问题。Php脚本是这样，其他的脚本也是这样

上一页  [1] [2]