本文作者：非主流
测试文件的源码如下：
我们先直接加上单引号试试：
http://192.168.0.20/conn.asp?id=1%27
很好，没有报错。那我们继续，and 1=1 和and 1=2，被拦截了。这个时候，我们可以看看到底是什么规则，发现每一个单独提交都不被拦截，组合到一起便被拦截了，好，那我们变通一下，用+代替空格
不再被拦截，Gogogo。
http://192.168.0.20/conn.asp?id=1+and+1=@@version 看看当前数据库的版本
http://192.168.0.20/conn.asp?id=1+and+1=user 查看当前连接数据库的用户
http://192.168.0.20/conn.asp?id=1+and+1=db_name() 查看当前连接的数据库
但是，当我们想查看有多少数据库的时候，发现被拦截了。怎么办？绕！
但是怎么绕呢。。依次测试吧，从左至右，开始依次加sql注入的关键字，发现
下表仅显示被拦截项目
| 关键字 | and | select | top | name | from | master | . | ( | ) |
|---|---|---|---|---|---|---|---|---|---|
| and | X | ||||||||
| select | X | ||||||||
| Top | |||||||||
| Name | |||||||||
| from | |||||||||
| master | |||||||||
| . | |||||||||
| ( |
可以看出，两个关键字的时候，只拦截select，那么我们试试三个关键字(无select)的时候，主机卫士会拦截什么？发现什么都不拦截，只会报语法错误。。。
由此，我们得出一个结论，主机卫士一定会拦截select关键字，那么问题来了，他只拦截select吗？SeLeCt呢？经过不完全测试，发现当我们将select字符unicode编码后，不拦截
http://192.168.0.20/conn.asp?id=1+and+%u0073%u0065%u006c%u0065%u0063%u0074
但是，当我们尝试一次添加三个关键字的时候，主机卫士又拦截了(好累)。
http://192.168.0.20/conn.asp?id=1+and+(%u0073%u0065%u006c%u0065%u0063%u0074+top
那么我们来试试存储过程呢？
Mssql的存储过程定义如下：
那么，我们就需要试着在url中提交declare、set和exec，看看是否被拦截。
很好，没有被拦截，只是提示语法错误，那就证明我们可以利用存储过程去绕过主机卫士！
我写了一个存储过程，内容如下(红色字体是需要另外修改的)：
我将这个存储过程转化成16进制(hex)
所以最终我们的请求是：
登陆dnslog，可以看到接收到了123456的子域名请求，这里的123456便是我在mssql数据库中admin账户的密码。
当然有了方法一就自然会有方法二，不妨开一下我们的脑洞。既然主机卫士我们可以利用超长的文件名去绕过上传(类似于二进制的溢出)，那我们在这里是不是也可以通过提交超长的url去绕过他的get检查呢？想到就去做。
实验过程：
Mssql有注释语句，无论多长都不会影响到语句的执行，那么，我们试试
在select前面添加一个注释，内容非常多的1
咦，这是什么鬼？？？
会不会是主机卫士找到关键字后，在一定的位数之内找其他关键字，如果有便返回999，如果没有就继续执行呢？那我试试用注释把select孤立起来。
发现bypass，很开心哦。
转载请注明：即刻安全 » 使用hex编码绕过主机卫士IIS版本继续注入
