本文首發于先知社區

https://xz.aliyun.com/t/7992

前言：

之前做了很多web題都遇到過審計代碼的題目，命令執行、變量覆蓋等。但如果這些代碼是分布在一套源碼中（如CMS），需要我們去發現，去找到并會利用，就需要有一定的查找以及利用思路，這次測試的是BlueCMS1.6,重要不在于去復現這個CMS的漏洞，而在先了解一下整個審計思路還有過程是怎么樣的，去鍛煉自己的審計能力。由于我比較菜，所以有錯誤的地方也請師傅們指正。

何為白盒、黑盒、灰盒測試

審計代碼會經常遇到這三個名詞，這又代表是什么意思那？

黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。

白盒測試：已知產品的內部工作過程，可以進行測試證明每種內部操作是否符合設計規格要求，所有內部成分是否經過檢查。

灰盒測試更像是白盒測試和黑盒測試的混合測試，現階段對灰盒測試沒有更明確的定義，但更多的時候，我們的測試做的就是灰盒測試，即既會做黑盒測試又會做白盒測試。

其他理解來也很簡單，就比如搭建一個網站，黑盒測試是在不知道網站源碼的情況下，對各個功能進行測試看看是否有問題，而白盒測試則是知道源碼，可以從代碼入手，看看代碼是否有問題，灰盒測試就是兩者混合起來進行測試（個人理解，如有錯誤請師傅指正），當然這些概念還有更深層的知識，這里就不詳細介紹了。

白盒測試流程——BlueCMS1.6

由于初學代碼審計，通過BlueCMS1.6來進行練習，這里重點寫一些白盒測試如何進行分析

0x00:了解目錄結構

看到這么多，怎么入手，思路是怎么去做？直接去找SQL漏洞、RCE等估計有點困難，因為這也太多文件了，我看了很多大師傅們都是先了解一下整個目錄結構，這個目錄是作用于什么的，包含有哪些文件，找到核心文件，再進行入手，會將審計范圍縮小一點而且會節省不少時間。

├── admin 后臺管理目錄 ├── install 網站的安裝目錄 ├── api 接口文件目錄 ├── data 系統處理數據相關目錄 ├── include 用來包含的全局文件 └── template 模板

看到以下函數也需要注意：

函數集文件，通常命名中包含functions或者common等關鍵字，這些文件里面是一些公共的函數，提供給其他文件統一調用，所以大多數文件都會在文件頭部包含到它們，尋找這些文件一個非常好用的技巧就是去打開index.php或者一些功能性文件，在頭部一般都能找到。

配置文件，通常命名里面包括config這個關鍵字，配置文件包括Web程序運行必須的功能性配置選項以及數據庫等配置信息，從這個文件里面可以了解程序的小部分功能，另外看這個文件的時候注意觀察配置文件中參數值是用單引號還是用的雙引號包起來，如果是雙引號，則很大可能會存在代碼執行漏洞。

當然不一樣的CMS，會有不同的目錄結構，但大多文件夾的名稱和對應的功能是不會有多大變化的，誰想在開發的時候整一堆亂起的文件名，到時自己測試都頭疼。

0x01:從首頁獲取信息

了解文件目錄后，就先從index.php文件入手，index.php一般是整個程序的入口，通過index文件可以知道程序的架構、運行流程、包含那些配置文件，包含哪些過濾文件以及包含那些安全過濾文件，了解程序的業務邏輯，所以從首頁入手是很有必要的。

但index.php這么多行，都要看豈不是太累了，而且沒什么用，因為index.php往往不需要獲取用戶輸入,那我們就看這個文件引入了哪些文件，逐層遞進。

引入了這兩個文件，我們上面提到過一定要注意含有common關鍵字的文件，打開common.inc.php觀察一下

在30多行發現了addslashes() 函數對全局數組POST，GET，COOKIES，REQUEST都進行了轉義處理，所以如果我們對包含該文件的文件進行SQL注入就要注意單引號、雙引號等會被轉義。

又觀察到會ban IP,可以了解這個文件主要是寫一些通用防護，其他文件引用即可使用

該文件包含了這幾個文件，如果到后面遇到看不懂的函數，可以通過跟蹤函數名在這些文件中搜索，就這樣先瀏覽一下大致的結構。

當然這里寫的不全，只是列出一點，但起碼這個層次關系還是多少搞懂點了。include目錄下的文件都是通用，就是讓文件進行引用減少不需要的代碼，從而提高效率，接下來寫其他頁面就相當于單獨寫，當需要引用這些文件時，只需引入即可，所以只要知道這些通用文件，當你在查看其他文件時有不懂的函數溯源查看即可明白這些函數的用途，從而繼續審計。

0x02:挖掘漏洞

跟蹤輸入變量

當看到一堆代碼時，會有那種不知所措的感覺，那就不妨想象一下一般網站出現漏洞的地方都是在哪里?比如SQL注入、XSS、RCE等會發現有一個共同點，就是用戶可以進行輸入，有輸入的地方就可能存在漏洞，所以這樣就有的放矢，在繁多的代碼中，就先去找一下那些用戶可以控制輸入的代碼。

從根目錄開始，就按照順序來，先看ad_js.php

$ad_id = !empty($_GET['ad_id']) ? trim($_GET['ad_id']) : '';

發現ad_id這個參數是可控的，再往下看發現SQL語句

$ad = $db->getone("SELECT * FROM ".table('ad')." WHERE ad_id =".$ad_id);

ad_js.php包含有common.inc.php文件，所以我們輸入的單、雙引號會被轉義，但是這里的sql語句中$ad_id是沒有單或雙引號包裹的，所以根本不需要去關注過濾，很明顯這里就存在了sql注入漏洞，先拿小本本記錄一下，這個文件含有SQL注入漏洞。

再來查看ann.php，90多行，但我們只去找用戶可以進行輸入的地方

$ann_id = !empty($_REQUEST['ann_id']) ? intval($_REQUEST['ann_id']) : '';$cid = !empty($_REQUEST['cid']) ? intval($_REQUEST['cid']) : 1;

但是經過intval()函數的處理后，便沒辦法進行SQL注入了，那就換下一個文件

查看news_cat.php文件，發現變量沒單雙引號但因為intval()函數無法進行SQL注入

再來查看user.php文件中也可能存在SQL注入漏洞，查看一下

同樣也是沒單雙引號而且沒進行過濾，應該是可以的，看一下$id是如何傳參的

因為intval()函數的處理所以這個SQL注入沒辦法利用了

利用工具去尋找漏洞

審計PHP代碼常用的工具有Seay源代碼審計系統、rips等，工具有時也會發現一些我們漏掉的地方，所以有時手工和工具同時使用效率會更高，利用Seay源代碼審計系統工具發現這么多漏洞，但要注意只是可能存在，有的不一定就是可以利用的。

還是去查找用戶能夠進行輸入的，畢竟一般漏洞都存在于輸入的地方，這個工具當你需要溯源的函數，只需全局搜索即可找到

查找危險函數

命令執行system、shell_exec、passthru、popen、proc_open

文件包含	require、include、require_once、include_once
變量覆蓋	parse_str 、mb_parse_str
代碼執行	eval、assert、preg_replace
文件操作	file_get_contents 、file_put_contents 、move_uploaded_file 、unlink & delete

這里列舉一些各個漏洞對應的危險函數，我們找漏洞無法就是RCE、SQL、文件包含等，那么直接查找這些函數，觀察這些函數是否可以利用，不就可以判斷出是否存在對應的漏洞了，比如查詢一下unlink函數

看到了一個$_POST，進行查看一下內容

存在可以利用的變量$_POST['lit_pic']，追蹤一下該變量

發現除了這四個文件含有這個變量，其他文件沒有包含有這個變量，除了開頭包含文件的轉義處理以外，沒用其他過濾地方，那就可以通過利用這個變量進行網站根目錄下任意文件刪除的操作。

0x03:分析漏洞

sql注入漏洞——UNION查詢注入

剛才在跟蹤輸入變量的時候，發現ad_js.php存在一個SQL注入漏洞，現在就來看如何利用這個漏洞

仔細觀察這段代碼，發現參數是沒有任何單雙引號，再去查找一下前面包含的這個SQL語句的getone函數，看看我們傳入的參數會不會因為這個函數而變化或轉義什么的，追蹤getone函數，發現在mysql.class.php文件中，功能用于封裝為sql語句，并沒有什么過濾等

這里啰嗦一下，之所以ad_js.php能調用這個函數，因為包含了common.inc.php，而common.inc.php并非在開頭引入了這個文件，而是在62行才引入，所以有的引入不一定就在開頭，最好使用工具去查找。

接下來再回到ad_js.php，發現這段代碼

echo "<!--\r\ndocument.write(\"".$ad_content."\");\r\n-->\r\n";

內容直接回顯，這不就是CTF常見的聯合查詢注入嗎？試一下

利用order by查詢出一共八列，接下來就聯合查詢

數據庫出來了，7是回顯位，這接下來按照聯合查詢的套路繼續走就可以了，這里就不再詳細寫了

任意文件刪除漏洞

這里就涉及到了灰盒測試

在上面提到了user.php文件中存在可控的參數，現在就來詳細的來看一下

發現lit_pic這個參數是可以通過POST來進行控制而且沒有包括其他的條件，但前面有一個BLUE_ROOT，需要去搞懂它所代表的意思，在文件開頭發現：

只是定義一個常量，并沒有過濾什么的，所以是可以利用的，那接下來就去利用這個參數，但還有一個問題是在user.php文件下直接POST這個參數嗎？還是在來看看源碼吧，繼續查找發現這個參數是在提交編輯后的分類信息中的


那只需滿足該頁面下需要傳入的參數（填入必須的參數）即可

這里我先創建一個實驗的文件text.txt

進行測試

再來看下text.txt，發現已經被刪除了

反射型XSS

有的時候工具檢測不出來不代表就沒有漏洞，有的也需要自己去手動查看，比如在guest_book.php便存在一個反射型的XSS漏洞，但是工具并沒有檢測出來

在頁面發現了用戶可以進行留言的地方

查看一下源碼發現有點東西的

page_id是通過POST直接傳入的，而且查看showmsg這個函數的定義也沒有對內容進行任何處理

所以這個漏洞是絕對可以利用的，傳入必要的參數即可引起反射型XSS

至于為什么常規的<script>alert(/xss/)</script>不行，觀察代碼，要想我們的語句起作用，就需要把前面的<input>標簽給閉合掉，所以才加上了">
所以工具沒測出來的，并不代表就沒有漏洞，還是遵循那個原則，有用戶可以輸入的地方一定要看

總結：

當然還有很多其他的漏洞，這一篇主要是學習代碼審計的一些流程步驟，下一篇就專心來審計代碼。挖掘漏洞，利用漏洞！

參考博客

Somnus

總結

以上是生活随笔為你收集整理的PHP代码审计之旅的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。