前言

首先感謝手電筒的建議，建議我從Bluecms來開始學習代碼審計。感謝桑桑格，風哥的問題解答。文章主要是寫下我自己在代碼審計的時候所思所想。當然并不是太過嚴謹，也有可能存在錯誤。這里主要是寫出了審計SQL、XSS、CSRF、文件包含漏洞的思路。當然，還有比如變量覆蓋，代碼執行，邏輯漏洞，會話認證等等。以后有時間會整理。這里的思路是我自己的。當然也有大神有更好的想法。今后我還需要加油。

文章使用審計軟件seay源代碼審計，Bluecms 版本v1.6sp1

最后，希望每個學習的小伙伴都能劈風斬浪。

一、常用代碼審計思路

常見的代碼審計漏洞方式有：根據敏感關鍵字回溯參數，查詢可控變量，尋找敏感功能點，通讀全文。

下面是我的代碼審計方式，不正宗。各位隨意看看。以bluecms為例：

1、初步查看源碼，了解其架構。特別需要注意的是common.fun.php，mysql.class.php，user.fun.php等文件。（判斷出來沒有關系，來來來，通讀一遍就好。）

e.g：data文件夾包含一些配置文件，include文件夾包含了自定義的函數，類等文件。

2、我們都知道滲透的話，我們著重關注三點：輸入點，數據流，輸出點。那么首先我們可以打開網頁來判斷輸入點位置，常見輸入點位置用戶登錄界面，搜索欄，留言板，一些公告URL參數位置。

3、通過對應輸入點位置的代碼，追蹤數據流，主要關注是否存在過濾代碼。

4、判斷出錯函數是否被其他文件調用。大可能概率其他包含的文件也是存在的。

二、SQL注入漏洞審計 2.1、SQL注入總結

正常情況，sql注入的位置經常出現在登陸頁面，訂單處理等。注意x-forward-for以及client-ip也會經常出現。因為該值是主動獲取的。并不需要用戶輸入，所以經常性的不會進行過濾。在訂單系統里面多個訂單與購物車的交互，導致復雜性提升，容易出現二次注入。值得注意。

2.2、BlueCmssql注入審計舉例

首先查看用戶登錄位置，查看表單代碼，發現數據傳送給user.php文件。那么我們嘗試在源碼以及web前端當中分析該文件。

WEB界面展示：

很明顯這是一個登陸界面，那么我們嘗試輸入信息，抓包看看具體的參數。在抓取數據包當中我們發現輸入的變量有：user_name,pwd,safeconde,userful_time,from,act。結合我們輸入的信息，很容易判定user_name表示用戶名稱，pwd表示密碼，safecode表示驗證碼，useful_time我們猜測可能是時間戳。剩下的from,act暫時不清楚。

查看源代碼user.php文件，通讀全文我們了解到變量act的作用，代碼根據cat參數不同的值來執行不同的SQL語句。所以，我們通過seay源代碼審計系統來打開代碼文件并且搜索“do_login”,來查看參數值為“do_login”時，執行什么樣的sql語句。（注意：個人習慣我喜歡用nodepad++來查看，部分截圖是使用nodepad++打開，不影響閱讀）

由代碼可以發現輸入參數符合上面一系列if語句的判定之后會執行一個select語句。利用這個getone函數以及login函數來執行。很明顯這是自定義函數。我們定位一下該函數來查看一下該函數是如何定義的。發現該getone函數是mysql.class.php文件當中類class自定義的一個成員函數。Login函數是文件user.fun.php當中定義的函數。下面我們來分析一下該函數：

A、getone函數調用了一個query函數來執行，并且將結果賦值給變量$query，且通過函數mysql_fetch_array函數處理賦值到變量$row，最后返回變量$row。

注釋：mysql_fetch_array在結果集中取得一行作為數字數組或關聯數組。MYSQL_ASSOC表示關聯數組。

B、這里我們發現query函數依舊是一個自定義函數。定位函數來查看一下該函數。發現該函數依舊是在文件mysql_fetch_array當中。Query函數利用mysql_query來執行sql語句，并且返回。如果查詢失敗指定報錯信息內容

C、login函數登陸函數。利用getone函數執行SQL語句。num=1

那么總結一下，getone函數作用：執行sql語句，控制報錯信息，以關聯數組形式返回值。（注意查詢語句當中存在字符串“count(*)asnum”會將查詢結果轉化。查詢成功num=1,查詢失敗num=0）Login函數作用是帶入用戶名，密碼進入數據庫查詢并且返回第一行查詢結果且結果進行轉化查詢成功num=1,查詢失敗num=0。

到目前為止，我們可以分析一下數據流了。首先數據從前端上傳到文件user.php文件當中，act=do_login位置代碼。經過if語句進行基本判定然后執行sql語句，將數據上傳到數據庫。這里我們沒有發現任何過濾的函數。看到這里我們很有理由懷疑該位置存在漏洞。值得注意的是，這里的login函數首先判定用戶名是否存在在執行用戶名以及密碼的聯合查詢。這里我的想法是驗證用戶名。那么我合法的注冊一個就是咯。下面我們查看playload:

我這里注冊了一個賬號abc123/abc123

注入位置參數$pwd。‘）用來閉合md5加密。

Playload:abc123‘）or 1=1 #

Playload:abc123‘）or 1=1 #

注意：在我測試的過程中發現了一個很不愉快的事情。我發現這么注入沒有任何效果。感覺像是單引號被干掉了。關于這個問題，我的思路是，采用var_dump來看看情況。下面是我處理該問題的思路：

使用var_dump來查看輸出變量的值：

很明顯這里的單引號被轉義了。這個時候我們想過造成該轉義的大多是使用函數addslashes，通過搜索，我們發現在文件common.inc.php當中發現自定義函數deep_addslashes

接著我查詢什么文件包含了該文件。通過搜索發現在文件common.inc.php文件被調用且該文件也被user.php文件使用。

那么問題就很好解決了。通過%df來嘗試繞過該函數。結果發現成功了。

那么更新payload:abc123%df’)

這里我決定使用sqlmap來掃描。結果掃描成功。

截至到目前，一個sql注入已經被挖掘出來了。這個時候我們考慮一下，文件user.php當中還有其他的執行的sql語句，并且沒有過濾。嘿嘿。是不是也存在相應的漏洞呢。

三、XSS漏洞審計 3.1、XSS跨站腳本攻擊總結

首先我們先了解一下XSS漏洞，說白了就是讓客戶端執行了一串惡意代碼。無論是一次性執行還是存在在服務器里面多次執行。那么他的危害是什么呢？準確來說，前端利用代碼能夠做到什么，XSS就可以做到什么。那么想要達到這個效果。我們該過程的核心是什么？輸入點？還是數據流？我的理解是數據流。即在數據傳輸過程中的變化。也可以這么說我們提交的數據在傳送過程中是否被過濾。

既然核心在于數據流，我們反過來考慮。我們在輸出點的位置查看變量。回溯看看該變量是否存在過濾，以及輸入位置。常見的一些輸出函數有：print，print_r，echo，printf，sprintf，die，var_dump，var_export。

常見的XSS漏洞位置：文章發表，評論回復，留言，資料設定等位置。

注意：瀏覽器的容錯，編碼等特性

3.2、XSS漏洞舉例

這里我打算舉個存儲XSS例子。首先我們思考一個問題，存儲XSS是將代碼存入數據庫當中。那么在PHP代碼當中存入輸入所使用的sql語句是什么呢？沒錯insert into 。那是不是存在存儲XSS必要條件是存在該語句呢。好的，現在我們搜索一下。

大家是不是很奇怪，紅框為什么不包含下面的文件。嗯，各位仔細看看，那特么特么需要管理員權限才能進去的。我要是有管理員權限，我會折騰這個？？？

好的，我們依舊選中user.php文件，打開并且定位到insert位置。

現在語句位置我們已經清楚了。現在我們查看賦值變量是否存在過濾。或者我們可以先登錄界面看看什么樣的變量是我可控的。即輸入點。奇怪的是變量act=do_reg的時候不能打開界面，我們發現參數等于reg的時候可以開。

右擊查看源碼就可以發現，點擊“提交注冊”，act的值會修改為do_reg。

好的，現在我們發現可控的參數用戶名，密碼，郵箱，驗證碼，當中驗證碼需要與后臺驗證不可控。密碼會經過MD5加密，折騰了意義也是不大的。那么接下來看看用戶名，郵箱，用戶名長度限制。這里最好的選擇就是郵箱這個參數。結合上下文看看，變量郵箱沒有被htmlspeciaichars函數過濾。我們來試試彈一個。 。

很快我發現了一個很尷尬的問題，格式不對。回頭查看源碼，發現報錯信息。并且當變量uid等于-4的時候，會出現這樣的報錯。找了半天發現沒有找到。估摸著是前端驗證。抓包輸入吧。

注意：這里我們需要考慮一個問題，即輸出點的位置是否在屬性內。

抓包并且成功注入。（做完忘記截圖了，各位自己想象吧）

查看數據庫當中確實已經存儲：

登陸賬號彈框：

代碼執行位置：

四、CSRF漏洞審計 4.1、CSRF漏洞總結

簡單說CSRF就是攻擊者通過手段來利用被攻擊者來執行被攻擊者具備權限的操作行為。在針對這些CSRF漏洞通過token就可以很好的防護。那么對于我們代碼審計來說。是不是重點關注存不存在token就可以很好的判定是否存在CSRF漏洞了呢？完美！！！

這里有必要說明一下token的認證方式：

1、前端傳賬號密碼給后端。

2、后端驗證成功之后將賬號密碼作處理加密生成token,并返回給前端。

3、前端收到token之后會存儲。

4、以后每次前端請求資源，需要驗證token，驗證成功則返回請求資源。

1、前端傳賬號密碼給后端。

2、后端驗證成功之后將賬號密碼作處理加密生成token,并返回給前端。

3、前端收到token之后會存儲。

4、以后每次前端請求資源，需要驗證token，驗證成功則返回請求資源。

有點難受啊，代碼水平的不足讓我沒有辦法例舉出典型CSRF。有點小失望。話說回來，針對該漏洞的審計我更喜歡黑盒。絕大多數會登陸幾個頁面，看看有沒有token，或者，刪除referer信息。看看訪問是否存在問題。如果不存在那么大多數情況可以確定存在CSRF漏洞的。至于白盒。我沒有太多的心得。基本就是看看有沒有設定token的代碼。

哎，我在考慮怎么來更好的說明這個呢。看了一圈Blucecm好像沒有這個token，這樣沒有辦法更好的說明。下面是我找打的一串設定token的代碼。看看這個。做到心中丘壑，這樣更好的為方便以后審計。

下面代碼是定義了一個token，使用時間戳以及隨機數生成的token。

下面我們可以看到，當我首次登陸的時候點擊按鈕是返回flase,這個時候并沒有獲取token,再次點擊按鈕會發現返回success.

注釋：這里的警告是因為我使用了php5.2版本，調整為7.3就沒有問題了。

五、文件操作漏洞 5.1、文件操作漏洞總結

這里我將文件包含，上傳文件，文件讀取，文件刪除，修改什么的等漏洞都統一稱呼文件操作漏洞吧。下面我們來聊聊這些操作文件的漏洞。

文件包含漏洞：在正常的編寫網頁當中一些代碼，類，對象定義之后會需要重復的使用。這個時候就需要用到一些包含的函數，比如include,include_once,require,require_once。可以在代碼運行的時候調用其它文件當中已經定義好的文件，類。本來是沒有問題的。但是，如果文件包含位置的內容是可控的呢？那么味道就改變了。一旦可控就可以去控制包含一些惡意代碼的文件。也就形成了漏洞。

注意：文件包含往往需要截斷。因為你的變量可控的位置后面還有拼接的字符串。而且恰好這個字符串是我們不需要的。截斷的手法往往和PHP版本有關。比如%00截斷

文件讀取（下載）：這個怎么說呢，就是還是可控的問題，讀取文件的變量可控，就可能造成讀取任意具備權限的文件或者下載。尋找這個漏洞，可以在網站先看看部分功能讀取什么樣的文件，抓包查看對應的變量。或則直接搜索文件讀取的函數。

文件上傳：這個玩意，主要出現點再能夠上傳文件的位置，比方說頭像上傳，文件上傳等位置。這個審計就比較直接了。找到具體上傳位置，查看對應位置代碼，看看有么有過濾就可以了。有的話就看看能不能繞過。當然了一下中間件本身自帶的漏洞也是可以利用的。

5.2、文件包含漏洞舉例

上面說了一些廢話，這里關于文件操作的漏洞，我選擇用一個文件包含漏洞來舉例。首先我們回顧一下文件包含漏洞的形成。可控的變量？是的。還有其他的嗎？答案是有的，函數include以及類似功能的函數對吧。那么我們先通過工具來全文搜索一下。來找到一個相對可能性比較大的目標。俗稱“踩點”

很明顯，我們一眼就相中了圖片紅框位置的包含函數。其中post傳參變量pay。那么下面我們點擊進去摟一眼，看看是不是打了眼。

看這一串代碼，發現如果變量是pay，那么就對一些變量進行賦值。說實在的啊，沒有太多的想法，打算到前端看看這到底是個什么玩意兒。在前端我們看到，這是一個“在線支付”按鈕的一個傳參。

既然輸入點已經找到了，下面我們在服務器里面放一個一句話木馬文件。看看能否利用該變量來打開我所放入的文件。

抓包，添加傳參：

注意：這里我看看傳參的位置：include ‘include/payment/’.$_POST['pay'].”/index.php”;

這里是后面添加的字符串“/index.php”是我們不需要的。這時候考慮的是如何截斷它，常見的截斷方式以后再整理。這里我們使用“.”來截斷。在window當中256個點可以達到截斷的效果。Linux需要2038

注意：因為這里我用的截斷是在PHP版本5.2上面測試的。如果有驗證不成功的。考慮一下php版本問題。

*本文作者：掌控安全獨行，轉載請注明來自FreeBuf.COM