0x01 前言

在一次漏洞挖掘项目中发现一个sql盲注漏洞，虽然漏洞点的识别并不复杂，但系统对注入payload的过滤机制异常严格。在多位师傅的共同探讨下，我们花费了近一天时间才最终成功绕过防护机制。现将这次实战经验整理成文，希望能为正在学习SQL手工注入技术的安全从业者提供有价值的参考案例。

0x02 漏洞详情

• 目标资产：购物商城页面
• 使用工具：Burp插件TsojanScan进行扫描
• 发现位置：商品查询页
• 漏洞参数：fncpdcode
• 具体参数为：

xxx.com?operNo=&token=&pageNum=1&pdAttr=&fncPdCode=1&.....

手动验证一下：

1）fncpdcode=1，正常查询页面：

2）fncpdcode=1' ，查询失败：

3）fncpdcode=1'' ，查询正常：

结论：单引号被代入数据库查询，证明存在bool盲注漏洞。

0x03 WAF绕过

接着使用DictFuzz/sqlDict字典进行fuzz测试，发现以下字符被过滤：

and 
or
|| 
&&
% 
<
> 
database  
=  
--
#

可以看到一些连接符、注释符、逻辑符号全被过滤，这么一来很多盲注的payload都用不了，比如常见的查询数据库名。

1' and ascii(substr(database(),1,1))>97 #

好在通过之后的测试发现user没被拦截，可以考虑注出数据库用户名证明危害。

1.利用exp函数实现逻辑判断

首先要构造一个payload，使之在数值变动时出现区别，但是这里>和<用不了，逻辑判断会比较困难，用这里采用的是exp函数，这里的知识点为：指数函数exp在每个数据库中的极限是不同的，超过一定数值就会报错返回null，通过exp函数的极限报错可以代替掉大于小于号实现逻辑判断。

这么说比较抽象，直接上图：

1）当exp(290)时返回结果正常

2）当exp(291)返回结果为报错

可以看到构造的payload为：

2'%7c%7cexp(290)%7c%7c'12

其中用'12代替注释符闭合注入语句，%7c%7c是||的url编码，代替or连接符，至于为什么是290报错，这是放到burp的爆破模块里跑出来的，大于290时返回值开始不一样。证明是该数据库的极限，也可以侧面反映这是个postgresql的数据库，感兴趣的可以自己本地搭一个postgresql测测，exp函数极限为290。

2.利用爆破模块遍历ascii码确定用户名

构造出区别点之后就能利用这个方式判断数据库用户名了,payload如下：

12'%7c%7cexp(999-(ascii(substr(user,1,1))))%7c%7c'12

这里的999要在burp的爆破模块里作为变量，遍历范围为可以选290到500，这样减去290就是0到210，ascii码最大127，足以覆盖掉所有字符。

首先通过该payload判断user用户名的第一位：

可以发现363的时候结果不一样，说明数363-据库用户名第一位字符的ascii码值为290,所以用户名第一位为chr（363-290）=“I”。

以此类推，爆破第二、三位，直到8位返回包结果不在变化，证明用户名只有7位，到此注入用户名证明漏洞危害。最后也是获得了高危评级。

0x04 总结

手注是考验sql注入理解程度及实战应用的必修课，找到漏洞点之后一般思路都是先fuzz过滤的字符后，在针对需要查询的目标，针对性构造对应payload。

关于各类字符过滤绕过手法文章非常多，这里就不赘述了，这里主要结合实战经历进行讲解，可能更有借鉴意义。

4A评测 - 免责申明

本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。

不得将上述内容用于商业或者非法用途，否则一切后果请用户自负。

本站信息来自网络，版权争议与本站无关。您必须在下载后的24个小时之内，从您的电脑或手机中彻底删除上述内容。

如果您喜欢该程序，请支持正版，购买注册，得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解！

程序来源网络，不确保不包含木马病毒等危险内容，请在确保安全的情况下或使用虚拟机使用。

侵权违规投诉邮箱：4ablog168#gmail.com（#换成@）