程式碼審計--11--原始碼審計思路（下）
2 按照業務型別正向審計
前面提到逆向回溯的審計方式針對特徵明顯的安全漏洞挖掘是非常有效的，但是同樣會有很多弊端，通過逆向回溯的方式只能對通用漏洞進行快速審計，不能全面挖掘更有價值的漏洞，如果在時間允許的情況下，企業中安全運營對自身產品進行程式碼審計，就需要了解整個應用的業務邏輯，比如越權類漏洞，需要了解應用中許可權劃分，每一級別使用者的功能，這樣才能很好的發現並確定哪些操作是非法的。
1、某系統越權檢視任意使用者個人資料
業務型別的正向審計通常從前端頁面開始，因為頁面會有系統中大部分功能展示，找出功能所對應的URL就是我們所審計資料流的輸入點，某系統修改個人資料處存在平行越權。
在客戶現場審計大部分情況是沒有測試環境的，也就是隻能通過前端的展示頁面對每一個功能進行審計。客戶會直接將專案程式碼交過來，首先要將它匯入編輯器，如果屬於Eclipse匯出的專案直接匯入就可以，但是相對來說沒有這麼理想的情況，那麼可以使用程式碼編輯器，例如SublimeText，如下圖：
可以直接將資料夾拖拽左邊目錄樹，拿到4個程式碼包，溝通了解到coreServer為核心業務程式碼屬於model層，apiServer為前端的API程式碼屬於controller層，jspxcms為CMS核心和後端管理程式碼屬於view層，cas為單獨的單點登入服務包暫時不在此漏洞的審計範圍內。
在進行審計之前我們要了解整個應用的架構，通過檢視web.xml瞭解到專案採用SpingMVC架構，並且未在web.xml中配置安全過濾器、身份校驗機制，如下圖：
SpingMVC的常用@RequestMapping註解為控制器指定可以處理哪些 URL 請求，也就是說可以直接通過在控制層搜尋URL請求，即可找到控制層所對應的業務邏輯程式碼。
通過檢視jspxcms中html頁面找到修改個人資料的功能頁面user/profile.html（可以通過關鍵字去搜索相應功能頁面，比如使用者中心搜尋user，修改密碼搜尋password），如下圖：
請求的URL會在js檔案中，也會在form表單中。
當找到檢視個人資料請求的URL後，可以通過SublimeTxt的全域性搜尋找到apiserver中所對應的業務邏輯程式碼，如下圖：
跟入coreServer中userService類中進行審計，如下圖：
2、Jeebbs郵箱邏輯驗證漏洞：
Tips：Eclipse全域性搜尋關鍵字方法：
根據搜尋結果找到對應檔案：
根據結果找到對應的public class RegisterAct類，並檢視對應邏輯程式碼：
找到控制層的入口後即可在對應的方法內設上斷點，然後傳送請求到控制層的URL進入Debug模式。
註冊傳送資料包時用Tamper data攔截並修改請求當中的email為xss攻擊程式碼。
選擇任意物件右鍵Watch即可檢視對應的值（任意完整的，有效的物件包括方法執行）。 F6單步執行。
F5進入validateSubmit：
F6跟到125行註冊呼叫：
F3可以先點開registerMember類看看：
找到介面實現類即最終的註冊邏輯程式碼：
3、積分負充漏洞
積分兌換方法如下：
@RequestMapping(value = "/member/creditExchange.jspx")
public void creditExchange(Integer creditIn, Integer creditOut,
Integer creditOutType, Integer miniBalance, String password,HttpServletRequest request, HttpServletResponse response) {}
可以看到這裡直接用了SpringMvc注入引數，而這些引數恰恰是控制程式邏輯的關鍵。比如構建如下URL，通過GET或者POST方式都能惡意修改使用者的積分：
http://localhost/jeebbs/member/creditExchange.jspx?creditIn=26&creditOut=-27600&creditOutType=1&miniBalance=-10000000&password=wooyun
因為他的邏輯是這麼寫的：
if(user.getPoint()-creditOut>miniBalance) {
balance=true;
} else {
flag=1;
}
從User物件裡面取出積分的數值，而積分兌換威望具體需要多少是在確定兌換關係後由ajax去後臺計算出來的，提交的時候也沒有驗證計算的結果有沒有被客戶端改過。其中的creditOut和miniBalance都是我們可控的。所以這個等式不管在什麼情況下我們都可以讓它成立。
4、打招呼功能處XSS
邏輯有做判斷：1、使用者名稱為空。2、不允許傳送訊息給自己。3、使用者名稱不存在。
在控制層並沒有做過濾：
在呼叫com.jeecms.bbs.manager.impl. BbsMessageMngImpl.java的sendMsg方法的時候依舊沒有過濾。到最終的BbsMessageDaoImpl 的save方法還是沒有過濾就直接儲存了;
一般性的做法，關係到使用者互動的地方最好做referer和xss過濾檢測，控制層負責收集資料的同時最好處理下使用者的請求，就算controller不處理起碼在service層做下處理吧。
