union + select 拦截
- select + from 拦截
- union + from 不拦截
#注释拦截掉了,--注释不拦截。--和换行url转码后为%2d%2d%0a
百度云加速+阿里云盾:
百度云加速更有意思,%23%0a拦截,%23%0d%0a又可以绕过
腾讯云安全+创宇加速乐:思路反馈给我的姿势
0x01百度云加速:
Bypass Payload:
0x02阿里云盾:
Bypass Payload:
0x03腾讯云安全:
绕过思路:
首先看看腾讯云安全怎么检测sql注入的,怎么匹配关键字会被拦截,怎么匹配不会?
那么关键的点就是绕过这个select,Bypass sql注入防御通俗点理解就是 第一不被waf检测到,第二sql能正常执行。select不行就找和select相同类型的,比如:
既然这些都可以,再想想使用这样的语句怎么不被检测到,达到天衣无缝的效果?
select 与 all 中间肯定不能用普通的/**/这种代替空格,还是会被视为是 union + select
select all 可以这么表达/*! select % 20all */,很明显不可行。还是属于 union + select
select all 还可以这么表达/*! 12345select all */,腾讯云也会认为是 union + select
尝试了下/*!*/中间也可以使用%0a换行
/*!12345%0aselect%20all*/还是会被拦截,这就说明腾讯云在语法检测的时候会忽略掉数字后面的%0a换行,虽然属于union+12342select,但简单的数字和关键字拆分再识别还是做得到。
再测试/*!12345select%0aall*/,结果就合乎推理了,根据测试知道腾讯云安全会忽略掉%0a换行,这就等于union+12345selectall,不会被检测到。(忽略掉%0a换行为了过滤反而可以用来加以利用进行Bypass)
可能会问,推理的依据并不能真正意义上证明忽略掉了%0a啊?当然要证明下,/*!12345%0aselect%0aall*/就被拦截了,说明刚开始检测到12345%0aselect就不再检测后方的了,union+12345select就已经可以拦截掉了。
还可能会问,既然忽略掉了%0a,那么/*!select%0aall*/是不是也可以啊,然而并不行。
合理的推理很有必要。
Bypass Payload:
测试案例:
Bypass:
0x04创宇加速乐:
和腾讯云安全的Bypass方式一样。
Bypass: