作者：會上樹的豬 合天智匯
0x00 SQL注入漏洞：
簡單介紹一下SQL語句：通俗來理解就是開發者盲目相信用戶，沒有嚴格檢查用戶輸入，導致用戶可以輸入惡意參數進入程序邏輯，最終拼接惡意參數改變原本的SQL語句邏輯，造成SQL注入漏洞。
0x01 關于CMS
本次審計的CMS是基于Web應用的B/S架構的團購網站建設解決方案的建站系統，它可以讓用戶高效、快速、低成本的構建個性化、專業化、強大功能的團購網站，采用php和MySQL數據庫開發技術，版本CV1.6。商業案例如下：
審計結果實戰測試：
0x02 漏洞分析：
首先在本地搭建一個網站，方便之后測試，一鍵安裝也沒啥說的，跳過。重點講講這個團購CMS的SQL操作。這個團購CMS將SQL操作全部寫到了
include/library/DB.class.php文件：
然后分析這個文件，發現這里面的函數有些使用了：mysql_real_escape_string函數對參數進行過濾，整數參數就強制轉換int類型
關于mysql_real_escape_string函數的注入可以嘗試寬字節注入，當數據庫編碼采用GBK的時候可以嘗試bypass函數檢查，但是此處不適用。之后審計發現其中存在幾個未對參數進行過濾直接執行SQL語句的函數：GetDbRowById、GetQueryResult、GetField。
此處采用敏感函數回溯的方法進行審計，先全局搜索這些函數，然后想辦法對達到觸發條件。
- 全局搜索GetField函數，發現沒有被引用的地方。
2、全局搜索GetQueryResult函數，搜索結果比較多，如下：
先嘗試審計第一處：/ajax/manage.php，如下，如果存在，可以通過$id變量進行注入。
追蹤如何觸發函數：第490行，當變量action滿足條件即可：
而繼續回溯，$action的來源$_GET:
同時也發現id變量被強制類型轉換了，哦豁，這下安逸了，這個點基本利用不了了。同時測試過程中此處還有一處調用了未過濾SQL函數：
不過都用到了ID參數進行注入，所以不能利用，放棄。
之后選擇其他可能存在的地方繼續審計：/manage/user/index.php
但是這兩處同樣存在intval參數過濾。
再繼續搜索，發現/manage/vote/feedback.php
此處$question[‘id’]參數來源于前一個查詢結果，可以考慮二次注入，不過此處因為id參數為提交問卷時系統自動生成，所以無法利用了。
最后兩處調用這個函數的地方在DB.class.php中：其中一個屬于LimitQuery函數調用，因為存在過濾，所以利用比較困難：
另外一處便是GetDbRowById調用，此處不存在過濾，可能存在注入，這個審計便放到下一部分：
- 全局搜索GetDbRowById函數：根據之前的審計，函數本身沒有對參數過濾，其中調用的GetQueryResult函數也沒有過濾，可能存在SQL注入。
可以發現GetDbRowById函數在
include/library/Table.class.php文件存在調用：_Fetch函數和FetchForce函數
其中_Fetch函數在同類中的Fetch方法被調用：
因此需要全局搜索Fetch函數和FetchForce函數：
首先來搜索FetchForce函數，結果如下，還挺多的
首先要說的就是搜索的結果不一定全部存在注入，需要再次尋找其中疏于過濾的點進行驗證，下面舉幾個栗子：
文件：/ajax/chargecard.php
不需要登錄便可以直接訪問這個文件，當$action為query時可以調用函數，且$secret不存在過濾，開啟debug調試跟蹤參數的流程：先輸入secret=123’
可以看到對secret參數沒有進行任何過濾便傳入FetchForce函數：
將存在惡意字符的參數拼接SQL語句，造成SQL注入，因為此處存在對空格等字符的正則匹配，所以可以使用/**/代替空格。
因為此處不存在回顯，要使用盲注，使用時間盲注驗證，一個用時2秒，一個用時5秒
而且同文件下存在另外一處注入：
這個地方用方法也差不多，就改一下action參數便可以。
再舉一個不存在注入的情況：/ajax/manage.php
雖然調用了FetchForce函數，但是溯源之后發現對id變量進行了強制轉換，因此屬于不能利用的點。與此同時new.php也屬于同理情況：
同時如果繼續搜索審計就能發現其他存在注入的點：
其余的文件就不一一看了。
接下來查看Fetch函數：搜索結果如下
先來看文件：/ajax/system.php
不過這個地方應該是需要管理員登錄的，登錄之后傳參是這個亞子的：
可以采用和之前相同的時間盲注：
再看另外一處漏洞：/api/call.php，此處不需要任何登錄，可以在前臺直接訪問到文件，而且其中多個參數存在注入：
再之后很多便與上面的審計方法類似，還存在可以利用的點，也會存在許多無法利用的點，就不一一寫出來了。
上面這個注入點還找到一個案例：
不過存在問題的便是這個CMS的密碼加了一個固定字符串當作鹽，在解MD5時會存在困難。
0x03 總結：
按照慣例，來小結幾句。
關于SQL注入的防御，應該有很多方法了，首先就是不信任用戶輸入，嚴格過濾參數，之后的話還可以使用預查詢方案，之后的話還可以使用軟硬件防火墻。不過這些理論上都會存在bypass的情況，不過我太菜，不會bypass。
另外就是關于參數過濾，如同上面，執行參數過濾，但是依然找到了漏網之魚，所以過濾策略某種情況下也是不可靠的。
最后就是關于代碼審計了，代碼審計一時爽，一直審計一直爽，奧力給！！！
聲明：筆者初衷用于分享與普及網絡知識，若讀者因此作出任何危害網絡安全行為后果自負，與合天智匯及原作者無關！
