之前遇到乙個站點，經檢測存在sql注入，但是有waf存在，後來知道是綠盟的web應用防火牆。
後來在社群看到了一篇關於《sql注入繞過技巧》的文章後（原文：回過頭來重新進行手工，這次總算乾掉了waf。以下是自己對於本次滲透的一些學習筆記，包含一些繞過waf的技巧。
首先判斷注入點
id=161-(select 1) 返回另一篇文章，基本確定存在注入。
然後，嘗試通過union查詢來獲取資料，但是連線老是被重置，而且過於頻繁的請求還被封ip。所以確定有waf的存在。接下來就是考慮如何繞過waf進行注入了。
首先要獲知返回的列數
id=161.0order by%2b9 這樣的查詢可以繞過waf檢測，而一般的 id=161 order by 9 則不行。
接下來就容易多了，嘗試一下獲取資料庫版本
id=161444.0union(select-1.0,2,3,4,5,6,7,@@version)
返回正常，但是id=161 and 4>5 union select 1,2,3,4,5,6,7,@@version 則不行。
基於關鍵字的檢測，主要是去掉關鍵字邊界的空格，還有就是使用等效法代替被檢測的字串。比如上例，如果使用version()代替@@version則不行。還有id=161444.0有兩個作業，第一讓原來的查詢返回空，第二這是乙個小數，小數後可以直接接關鍵字，而不用空格。
是不是root呢，這很關鍵。
嘗試了這5個函式或變數都被過濾了：user(), current_user(), current_user, system_user(), session_user()
好吧，乾脆直接檢視mysql.user表算了
好了，是root，高興了。
這裡關鍵是反單引號的使用，成功逃過了敏感字串「mysql.user」的檢測。
這裡主要說的是注入，getshell就不說了。後來發現拿下c段的另一台伺服器後（假設是a），再通過a的遠端桌面訪問目標伺服器，然後進行注入是不受防火牆限制的。可能是因為防火牆放置在網路邊界的外圍某節點，而從內部訪問的資料並沒有經過該節點所致。
接下來在說說我遇到過的另一種sql注入情況
經過最初的手工判斷目標站點存在注入，而且同樣存在waf。剛開始碰到這種情況我也不知所措，然後一直跟著不放終於找到破解的方法。
當開始我從正面無法突破，於是想到了從非標準入口下手，然後掃瞄目標伺服器開放了哪些埠。發現目標除了開80還開了其他埠還有443，然後嘗試訪問https:www.example.com 發現和返回的結果一模一樣。
然後想有沒有可能waf只過濾了其中乙個埠，事實證明運氣就是這麼好.
在後來通過嘗試也找到了證明突破的方法
又是root，運氣好沒得說。
在這裡並沒用使用反單引號來waf對字串「mysql.user」的檢測，還是採用了兩次url編碼的方式將即：mysql%252euser。
為什麼可以這樣呢，因為waf只對請求的字串進行一次url解碼，而後端的web server卻進行兩次url解碼。所以waf認為沒有危險的字串，就因為這樣的的失誤造成了危害。
mysql手工注入繞過 sql注入繞過WAF
這幾天的ctf題中有好幾道題都是sql注入的，但都存在waf需要繞過，於是整理了一些常見的繞過waf注入的方法。在現實sql注入中我們也常常碰到waf，那麼掌握常見的繞過很有必要。0x01 手工注入繞過 1 大小寫混合例如 union select 1,2,3,4 只適用於針對大小寫關鍵字的匹配 2...
mysql注入轉義繞過 SQL注入防禦繞過
一 寬位元組注入 1 什麼是寬位元組 gb2312 gbk gb18030 big5等這些都是常說的寬位元組，實際為兩位元組 2 寬位元組注入原理 防禦 將 轉換為 繞過 將 消滅 mysql在使用gbk編碼的時候，會認為兩個字元為乙個漢字 編碼為 5c 編碼為 27 df 5c mysql會認為是...
mysql 注釋 繞過 sql注入繞過方法
一 注釋符號繞過 在sql中常用的注釋符號有 二 大小寫繞過 當web正則過濾的時候對大小寫不敏感的情況下使用，一般很少會有這種漏洞 比如當過濾了select的時候我們可以採用select來查詢 三 內聯注釋繞過 把要使用的查詢語句放在 中，這樣在一般的資料庫是不會執行的，但是在mysql中內聯注釋...