另内寻找“隐藏”的搜索型注入点

我首先对这些人才网进行了一些安全检测，可以发现一些明显的可能存在注入点的数字和字符都被过滤了，但是搜索型的呢？在我所检测的人才网中，我发现相当多的人才网都存在着搜索型的注入漏洞，不过这种漏洞相对来说是隐藏的，下面就让我们找出它们吧。
        一般的人才网都存在着搜索页面，可以输入关键字来搜索需要的信息，所以部分匹配的SQL语句可以这样写：“Select 相应的字段 from table_name where name Like '%keyword%'”，也就是所谓的模糊查询了。这样，数据库中只要含有我们搜索的关键字，所有的信息就会被查询出来了。当然这只是一个例子，为了更精确的查询，有时候SQL语句还可以写成完全匹配的模式，其道理是一样的。如果keyword没有进行过滤的话，那我们就可以在搜索框中输入这样的语句来查询，如“计算机%'and 1=1 and '%'='”，此时查询语句就变成了“Select 相应的字段 from table_name where name Like '%计算机%'and 1=1 and '%'='%'”，然后再把其中的“1=1”换成“1=2”提交，若查询返回的页面是空的，则说明没有过滤，注入就产生了。
    我们知道，From中的数据传输过程分别对应了HTTP协议中的Get和Post方法。我在网上曾看过一个关于搜索型注入的动画，其搜索的内容经过URL编码后，直接在IE地址上显示出来，也就是说用Get的方法提交的数据，Get方法保存在request的querystring集合中，懂点ASP的都明白这个道理。Get是默认的方法，但Get是不安全的，因为在传输过程，数据被放在请求的URL中，而如今现在的很多服务器、代理服务器或者用户代理都会将请求URL记录到日志文件中，然后放在某个地方，这样就可能会有一些隐私的信息被第三方看到。另外，用户也可以在浏览器上直接看到提交的数据，一些系统内部消息将会一同显示在用户面前。对于用Request.from()来获得表单提交的数据用的是Post方法，这个查询提交的变量在地址栏中是看不见的，Post方法提交的数据保存在request方法中的form集合中。Get将表单中的数据按照variable=value的形式，添加到action所指向的URL后面，并且两者使用“?”连接，而各个变量之间使用“&”连接；Post是将表单中的数据放在Form的数据体中，按照变量和值相对应的方式，传递到action所指向的URL。对于Get方式的搜索型注入很好查找和利用，像一般的注入点交给工具完成就可以了。Post方法的所有操作对用户来说都是不可见的，由于不在IE中显示，这种提交数据的特性相对Get方法来说隐藏了变量，查找起来不是很容易，这也就是所谓的隐藏的搜索型注入点了。有时候虽然可以用手工判断出有这种漏洞，但隐藏的变量找的不全，查询语句满足不了，只能通过手工来完成。Acess数据库表名和字段猜不对就不用说了，如果是SQL数据库，IIS错误提示又关闭的话，手工完成简直是一种折磨。所以这么累的事情，还是用工具来替我们完成吧，我们只需要自己动手查找出隐藏变量赋予正确的值并正确构造即可，这也是注入成败的关键所在。
        说了这么多理论，下面就来验证一下吧。随便选择一个人才网，在职位关键字里输入：计算机%'and 1=1 and '%'='%，所有符合条件的相关职位都出来了；再把1=1换成1=2，显示的是空白页面。由于采用的是post提交的方式，我们只能自己找出其中的变量并赋上相应的值，然后把值手动变成这样的形式http://www.xxx.com/query.asp?Value1=内容&Value2=内容&KeyWord=计算机，这样就可以把注入的工作交给工具来完成了。Value少的话，可以通过查看源代码的方式查找出来，如果只有变量一个的话就算了；但对于value非常多的情况下，就需要自己手动抓包来实现，这样的话就不会发生遗漏变量，导致查询条件不足结果不正确。
    打开WSockExpert监视你提交数据的页面，选中post抓取的数据，如图1所示。所有的变量都出现了，不用查看源文件了。其中的“PosiKey=%BC%C6%CB%E3%BB%FA”就是“PosiKey=计算机”，经过URL编码后就变成那样的形式了。“计算机”是我输入的关键字，为了便于理解，我将其还原如下：    



Industry=%D0%D0%D2%B5%B2%BB%CF%DE&DateTime=%CA%B1%BC%E4%B2%BB%CF%DE&Province=%B5%D8%C7%F8%B2%BB%CF%DE&City=%B5%D8%C7%F8%B2%BB%CF%DE&EduLevel=%D1%A7%C0%FA%B2%BB%CF%DE&Sex=%D0%D4%B1%F0%B2%BB%CF%DE&CompKey=&x=0&y=0&PosiKey=计算机

        这样，我们提交的URL就变成http://www.xxx.com/query.asp?Industry=%D0%D0%D2%B5%B2%BB%CF%DE&DateTime=%CA%B1%BC%E4%B2%BB%CF%DE&Province=%B5%D8%C7%F8%B2%BB%CF%DE&City=%B5%D8%C7%F8%B2%BB%CF%DE&EduLevel=%D1%A7%C0%FA%B2%BB%CF%DE&Sex=%D0%D4%B1%F0%B2%BB%CF%DE&CompKey=&x=0&y=0&PosiKey=计算机。这里还有一个问题，就是URL过长的话，有可能被截断，此时用工具就检测不出来漏洞了。由于URL过长，我使用NB的时候就失败了，后来发现用HDSI可以输入较长的URL。很快注入结果就被跑出来了，如图2所示。


    此时要注意了，由于注入工具判断注入方式的原因，我们要把查询的关键字，如“PosiKey=计算机”放在地址栏的最后，才可以检测出这样的漏洞，因为variable=value只是查询的一个条件而已，放在哪个位置是不重要的。不然的话，像NB和HDSI都是检测不出来注入漏洞的。用同样的方法，我们再来测试一下河南毕业生人才网，如图3所示。该数据库为Db_owner权限，如果Web和数据库不是分开的且列目录正常的话，得到WebShell应该是没有什么问题了。

        在我测试的过程中，发现有些基于Oracle数据库的人才网站也同样存在这样的安全隐患。虽然有的人才网查询表单用JavaScprit限制了提交字符的长度，但这也是不安全的。因为这些脚本在客户端是可以控制的，我们只需取消它的限制就绕过了长度限制，也就可以注入了。
        上面说所的情况，一般都是在表单允许我们进行输入的情况下进行的，但并不是每个站都允许我们在表单里输入查询的关键字，而只能选择给定的条件。表面上看完全没有问题，实际上同样存在注入漏洞。那么如何找出隐藏的变量来判断是否存在这样的搜索型注入漏洞呢？方法还是一样。用WSockExpert监视提交的页面，用URLEncode转换工具把你选择的关键字转换成URL编码，然后和WSockExpert抓取的数据进行比较，相同就是查询的关键字符了，余下的事情交给工具吧。这样的漏洞，我测试了几人才网站都没有过滤，有的权限还是sa，真为它们的安全感到担忧。有兴趣的朋友就在网上搜索吧，一定不会让你失望的。
        事实上，存在这种漏洞的网站不仅是人才网，基本上存在在搜索的地方，我们都可以检测一下。还有一点，在我用WSockExpert抓包的时候发现存在一个问题，如果数据过多的话，后面的数据就会覆盖前面的数据，致使我们抓取不到Post提交的数据，此时换用EffeTech HTTP Sniffer来进抓取，就可以完美地解决这个问题了。
        对于PHP程序来说，由于php.ini中一个非常重要的配置选项magic_quotes_gpc，高版本的默认配置是magic_quotes_gpc＝On，很老的PHP中的默认配置是magic_quotes_gpc＝Off。为On的情况下，我们提交“’”就会自动加上“\”，变成了“’\”。对于PHP的字符型来说，这点是致命的，也就失去了利用价值，不过也有例外的情况，还要根据服务器的设置和SQL语句的写法来具体分析。
    对于这种类型的漏洞的修补，一般来说，就是把单引号过滤掉，或单引号变成双引号，然后再把and、select之类的敏感字符全部过滤掉就安全了。从客户端提交数据到数据库查询时，对字符一定要过滤再过滤，即使是隐藏的变量，最终被发现也只是时间问题而已，脚本安全真的来不得半点的侥幸心理。