安全只有相对，没有绝对。(人才是最大的危险)

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是绕过了，没法绕过后面的检测。

 

 

 

 

解决方案：

唉，写了半天。。。挨个通知修复过滤吧。。。