0x00 可遇不可求的伪静态注入
某车企SRC挖掘的的一个注入，这个注入主要还是细心，注入点在URI链接中，借助一些常见的插件可能扫不出这个注入洞，简单判断，确定注入
![SRC中挖掘的SQL注入漏洞记录]( "SRC中挖掘的SQL注入漏洞记录")
获取库名证明危害
![SRC中挖掘的SQL注入漏洞记录]( "SRC中挖掘的SQL注入漏洞记录")
![SRC中挖掘的SQL注入漏洞记录]( "SRC中挖掘的SQL注入漏洞记录")
0x01 运算符处的SQL注入
某招聘企业SRC挖掘的一个注入，日常抓包，抓到如下请求与响应，一眼看上去也太像sql注入了
等号换成like可以初步绕过，但是服务端没有返回数据
疯狂尝试，都没戏，目光转移到orderBy参数处，但结果也一样，最后放置了一段时间，回过头来仔细分析了下，将注意点放在filters参数里
"filters":[["loginName","like","%%' and '1'like'1"]]
Filters里有三个数据，盲猜第一个是列名，第二个是运算符，第三个是数值
数值那块尝试了，有某云WAF，暂无法利用，将目光转向运算符位置
那么直接拼接到运算符处呢？结果服务端返回了正确的数据
![SRC中挖掘的SQL注入漏洞记录]( "SRC中挖掘的SQL注入漏洞记录")
最后在审核大大的指点下，根据指纹搜索了一波，算是个小通用漏洞，但是用的站比较少，就到此结束了
waf拦截了，仔细看了下服务器的响应：asp.net，直接hpp，构造payload，注意：参数值会通过逗号拼接起来，知道这个之后直接构造
这是一个比较有意思的order by后的注入，最终因database() select from注释符过滤的很严格，没有真正完成，简单记录下，希望以后有机会去完成它吧
order=&orderField=&page=1&limit=1&schoolname=
构造payload(各种尝试，此处order内容只能是schoolname，改成其它参数都会异常order=schoolname&orderField=schoolname&page=1&limit=1&schoolname=
order=schoolname&orderField=if(1=1,schoolname,1)&page=1&limit=1&schoolname=
![SRC中挖掘的SQL注入漏洞记录]( "SRC中挖掘的SQL注入漏洞记录")
![SRC中挖掘的SQL注入漏洞记录]( "SRC中挖掘的SQL注入漏洞记录")
两次结果不同，典型SQL盲注，直接跑数据，各种被干呀，database()、select、from这种的一直绕不过去啊，最终无耐只能投机取巧获取current_user的值
直接intruder跑就完事了，比较好玩的是还需要对%进行编码，跑出的用户名的最后一位是%，结果我没有编码，导致一直卡在最后一个字符，然后本地库看了一眼，最后一位是百分号，要编码下才能出，坑是一直踩一直爽啊
原文始发于微信公众号（安全艺术）：SRC中挖掘的SQL注入漏洞记录
评论