最近有点倦怠了，越往上爬，视野越开阔，越觉得自身的不足。
记录一下之前遇到的一个比较怪的注入。
0x01 遇到注入
A参数点加单引号，报错
双单引号，sql语句正常执行，回显正常
后面依次判断了三个、四个单引号和存在注入点单双数量单引号回显一致，可以判断是存在注入的
0x02 尝试注入语句
出现注入，第一反应当然是sqlmap了，这里我首先用sqlmap跑了下
直接connection reset了
还是尝试手注吧，老样子，还是要把sql语句的拼接点找到，这里直接在报错里有了
也就是select * from testtable where id like '%[可控]%'
通常我们判断逻辑是用and、or、xor这些等等，这里直接就reset了，好家伙
换个关键词吧，用&&、||替换 发现还是不行
后面发现不是逻辑表达式的问题，当单引号为奇数的时候是可以的：
感觉像是如果and给站弄崩了的保护机制？当然，我是瞎猜的，因为默认也是出所有数据的
这里还是用&&和||来注入，不断的尝试，出来了一个判断布尔的语句：'&&'1'='1'|'这里又有问题，如下 页面异常
页面正常
同样的语句，页面不同，估计是服务器配置问题或者是waf问题，咱也不敢说，也不敢问……
0x03 尝试注入数据
取数据的时候，是需要用到函数的，但是这里又有一个问题，无论输入什么函数，只要有()的，都会connection reset
第一反应可能是拦截了关键字，比如一些if()、ascii()、substring()这种的，都会拦截，所以我直接掏出来了mysql函数进行fuzz，发现没有一个不拦截的
感觉不是拦截关键词的原因，可能是waf的特征了 这里我尝试了很多方法，内联注释、%0a一些字符的换行，注释符等等发现都不行
/*!if*/()、if/**/()、if%0a()……
后面也是用注释符乱试，发现了一个语句竟然可以成功'&&if(/**/1=1,/**/1, current_user)='1'||'
解释下这里第二个的表达式为什么是current_user
一般来说，我们会使用if(1=1,1,0)来进行注入数据的 但是这里是不行的
直接reset了
本地尝试下还有哪些参数可以用的
本地来看，也就是存在有效参数就可以执行语句
实际环境中，是不行的
用id、甚至是sql语句里的字段直接都是reset
这里我就想到了，如果用一些变量呢，比如说user()、database()之类的，本地：
本地正常执行
实际环境中，又是reset了
但是想到之前任何字符加上括号就会被reset的问题，那就user()换成current_user，执行成功 正常回显，结果为true
正常回显，结果为false
接着注入数据'&&if(/**/ascii(substring(/**/current_user,/**/1,1))>113,/**/1,/**/current_user)='1'||'
114用ascii直接转换
得到用户名第一位为r
0x04 总结
-
遇到注入要不停的尝试，试出过滤、拦截了什么特征，再去绕过 -
还是那句话，得知道什么位置拼接的，本地执行可以更快的进行SQL注入
原文始发于微信公众号（only security）：注入绕过案例之三
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/204232.html
