這道題目算是給了sql注入另外的思路了。一般而言我們測試sql注入會選擇那些有直接顯示的地方（比如id=1，name=***），但這會侷限你的思維，所以一定要多多培養做題的思路才能應對各種情況。下面會給出不一樣的思路：
1.這是墨者學院一道有waf的sql注入，有很多人遇到有waf的環境就感覺頭大，確實繞waf很頭疼，但waf也有強弱之分，我們要做的就是測試一下對方伺服器的waf做了什麼，根據waf的特點來繞過它。
2.從下圖我們知道，該waf是檢測輸入的引數值是否存在一些進行sql注入的字元，如果有就彈出警告並記錄在伺服器中。
3.因此我們沒有必要死磕在怎麼繞過waf的上面了，可以換個思路。它不是會把我輸入的字元存在伺服器上某個檔案下嘛（一般是日誌檔案），那我構造一句話木馬傳過去不是正好？
這裡提個題外話，下面這個是通過f12開發者模式檢視器得到的「原始碼」。
而通過檢視網頁源**得到下面的結果。可以發現兩者並不一致，下面的才是真正的經過伺服器端處理後傳給瀏覽器的原始碼，而上面的是在瀏覽器處渲染後的結果。
4.這時把我的一句話木馬傳過去後發現caidao並不能連線（也有可能能連線，畢竟這是乙個公開的靶場，可以把pass換成有獨特性的字元。還可能是因為之前可能連線過一次，把cookie存下來了，可以通過清空一下caidao的快取），如果出現了這種情況，那麼這就牽扯到url編碼問題了（這裡的sqlin.asp是通過目錄掃瞄得到的）
5.具體的可以上網去搜尋一下，這裡推薦
下述圖中，%20=空格，%3c=
5.因此，如果想要正確的傳入，需要把%編碼成%25傳過去，就能連線了。
之後就可以去caidao連線了。
6.總結：
1.首先是sql注入思路的拓展，不僅可以通過上述技巧，而且還可以測試cookie注入，referer注入，http header注入等，一切有可能和資料庫產生互動的地方。2.其次是url編碼問題，對於那些有歧義的字元需要編碼才能被正確地傳給伺服器。3.caidao的使用技巧，如果caidao連線失敗可以嘗試清除快取。
防SQL注入
這段 有好處也有壞處，用的時候得小心，搞不好就會跳進錯誤 dimsql injdata sql injdata and exec insert select delete update chr mid master truncate char declare sql inj split sql in...
防SQL注入
1.必須認定使用者輸入的資料都是不安全的 使用者輸入的資料進行過濾處理 if preg match w get username matches else 讓我們看下在沒有過濾特殊字元時，出現的sql情況 設定 name 中插入了我們不需要的sql語句 name qadir delete from ...
防SQL注入
與資料庫互動的 web 應用程式中最嚴重的風險之一 sql 注入攻擊。sql 注入是應用程式開發人員未預期的把 sql 傳入到應用程式的過程，它由於應用程式的糟糕設計而使攻擊成為可能，並且只有那些直接使用使用者提供的值構建 sql 語句的應用程式才會受影響。sql 語句通過字串的構造技術動態建立，文...