安全只有相对,没有绝对。(人才是最大的危险)
Mysql在执行语句时,#注释将忽略掉"当前行"后面的所有语句,但是即使忽略了注释后面的语句,遇到换行的话还是会紧接注释之前的语句继续执行。
再经过URL编码后为%23%0A
阿里云盾:
Bypass:
https://**.**.**.**/ask/3689?spm=5176.100241.0.0.eViKRY?id=1%20union%23%0Aselect%20user%20from%20ddd
百度云加速:
Bypass:
安全宝:
安全宝就比较有意思了,这个方法试了下不可行。
再看看安全宝怎么检测的:
只有union select不会被拦截。
当union select后面加上查询字段的时候就会被拦截,所以可以不必在union与select之间使用这个方法。
想了想,要是有方法配合%23%0A能绕过也可以啊,在union select%23与%0A之间做文章。
各种能想到的方式都试了个遍,也许大家猜到了故事的开头,却没猜到故事的结局。。。
想到了Emoji。。。(其实Emoji很久之前就想过了,但是一直没利用上,这回终于用上了。)
一个emoji图标占5个字节,mysq也支持emoji的存储,在mysql下占四个字节:
既然在查询的时候%23会忽略掉后面的,那么Emoji就可以插入到%23与%0A之间。
再加多试了试,成功绕过了,200多个emoji图标,只能多,但少一个都不行。。。
(这里暴露出一个bug,200多个emoji插入到code区域中时,发现emoji后面的内容全没了!!!也就是说我这后面是重写了两遍!!!所以截图吧。。。)
可能会说,这是因为超长查询导致的绕过吧?并不是。
这么长,mysql也是会执行的:
安全狗:
Windows Server 2008 + APACHE + PHP + Mysql
Bypass:
云锁:
Windows Server 2003 + APACHE + PHP + Mysql
360主机卫士:
和安全宝那个利用方式一样,也是需要结合emoji图标即可实现绕过注入防御。
Bypass:
可能会想,知道创宇的加速乐忘了?没有啊。。。其实这个方法加速乐可以是可以,但是相对来说,利用起来很鸡肋。union select是绕过了,没法绕过后面的检测。
解决方案:
唉,写了半天。。。挨个通知修复过滤吧。。。