這道題目算是給了SQL注入另外的思路了。一般而言我們測試SQL注入會選擇那些有直接顯示的地方（比如id=1，name=xxx），但這會局限你的思維，是以一定要多多培養做題的思路才能應對各種情況。下面會給出不一樣的思路：
1.這是墨者學院一道有waf的sql注入，有很多人遇到有waf的環境就感覺頭大，确實繞waf很頭疼，但waf也有強弱之分，我們要做的就是測試一下對方伺服器的waf做了什麼，根據waf的特點來繞過它。
2.從下圖我們知道，該waf是檢測輸入的參數值是否存在一些進行SQL注入的字元，如果有就彈出警告并記錄在伺服器中。
3.是以我們沒有必要死磕在怎麼繞過waf的上面了，可以換個思路。它不是會把我輸入的字元存在伺服器上某個檔案下嘛（一般是日志檔案），那我構造一句話木馬傳過去不是正好？
這裡提個題外話，下面這個是通過F12開發者模式檢視器得到的“源碼”。
而通過檢視網頁源代碼得到下面的結果。可以發現兩者并不一緻，下面的才是真正的經過伺服器端處理後傳給浏覽器的源碼，而上面的是在浏覽器處渲染後的結果。
4.這時把我的一句話木馬傳過去後發現caidao并不能連接配接（也有可能能連接配接，畢竟這是一個公開的靶場，可以把pass換成有獨特性的字元。還可能是因為之前可能連接配接過一次，把cookie存下來了，可以通過清空一下caidao的緩存），如果出現了這種情況，那麼這就牽扯到URL編碼問題了（這裡的sqlin.asp是通過目錄掃描得到的）
5.具體的可以上網去搜尋一下，這裡推薦https://www.cnblogs.com/jerrysion/p/5522673.html
下述圖中，%20=空格，%3C=<，%22="，這些全是經過浏覽器URL編碼的。而經過和原始資料對比發現，一句話木馬中的%并沒有被URL編碼，而當這個未被編碼的%傳過去後，會被伺服器端當做是編碼後的資料，伺服器會去檢視%後面的字元，而後面接的是字母，是以%會被丢棄掉，進而變成<eval request...>,進而不能被執行，導緻caidao連接配接失敗。
5.是以，如果想要正确的傳入，需要把%編碼成%25傳過去，就能連接配接了。
之後就可以去caidao連接配接了。
6.總結：
1.首先是SQL注入思路的拓展，不僅可以通過上述技巧，而且還可以測試cookie注入，referer注入，http header注入等，一切有可能和資料庫産生互動的地方。2.其次是URL編碼問題，對于那些有歧義的字元需要編碼才能被正确地傳給伺服器。3.caidao的使用技巧，如果caidao連接配接失敗可以嘗試清除緩存。