由于開源的JAVA WEB項目不是很多，這里找到一個沒有用struct2或是spring框架的cms，希望借此cms來幫助新手敲開JAVA代碼審計的大門，文章會詳細寫一些筆者進行審計過程走過的路，漏洞利用過程并不是多高深，大?？梢岳@過，此篇權當拋磚引玉~
系統(tǒng)基于租車業(yè)務場景而搭建的O2O服務平臺，可為用戶提供商務租車、接送機、旅游租車、企業(yè)租車、自駕租車、婚慶用車等自助租車服務。
系統(tǒng)包含車輛庫管理、門店管理、員工管理、司機管理、訂單管理、活動管理、評價管理、財務管理、統(tǒng)計等。
cms的下載地址：http://down.admin5.com/jsp/135501.html
下載完講一下安裝這塊，筆者的環(huán)境使用是tomcat8.5+phpmystudy，tomcat8.5部署web這個就不多說了，多百度百度自然就會了，這里的phpmystudy主要是需要使用到其中的mysql數(shù)據(jù)庫，單獨開啟mysql數(shù)據(jù)庫也行~
這里下載完有一個使用說明，對整個安裝流程介紹的還是非常詳細的，這里不再贅述~
這是網站首頁，然后我們來進行一個功能上的瀏覽與匯總，這里可能是習慣問題，筆者在做代碼審計的時候一般不會先看代碼，而是根據(jù)功能點去進行一個代碼的回溯，這樣做會減少大量的代碼審計時間，但是缺點就是一些不在顯示頁面的功能點所存在的漏洞可能就會挖掘不到，這里選擇可以因情況而異~
第一個功能點可能就是這個用戶的注冊功能，那用戶的注冊一般所存在的問題大多為sql注入、xss漏洞、邏輯漏洞、頭像處getshell等等，順著這樣的思路去找，效率上應該會大大提高。
第二個功能點可能就是這個主功能：租車服務。
但是這里點擊“立即預定”會跳轉到用戶界面，先放著，再看看其他功能點。
但是這個cms終究是一個小型的cms，整個功能不是很多，其余功能點并未找到~
那么我們來進行匯總！
審計的時候首先測試用戶功能點，這里首先是最常見的一些邏輯漏洞（任意密碼重置這類）、SQL注入、存儲型xss漏洞、后臺頭像getshell、訂單遍歷等等，之后再測試租車功能，看看有無邏輯漏洞（1元購）和訂單遍歷（修改ID獲取其他用戶的信息）等等，整個流程肯定大抵就是這樣，下面進入審計實戰(zhàn)！
首先有一個獲取手機動態(tài)碼，那么這里由于是本地搭建，肯定發(fā)不出去，分析一下，這里存在的潛在風險可能就是短信炸彈，這里看了代碼好像并沒有加上一些檢查機制，炸彈應該是存在的。
這里說下怎么進行代碼的回溯，我是采用的search，比如說這里的功能點為getTelCode，然后到eclipse中去進行全局的搜索，基本不到一分鐘就能定位到代碼。
由于注冊功能不完善，這里只能到后臺手工添加了一個賬號。
這里的“忘記登錄密碼”功能被閹割了，依然無法進行測試！
進入到個人中心，首先是功能點所引發(fā)的潛在漏洞匯總，映入眼簾的就是一個基本資料的修改：存儲型xss OR SQL注入？？
包括這里的資料修改和收貨地址修改其實都存在上述兩個問題，，這里選擇一個進行代碼跟蹤和測試即可~
訂單功能，會不會出現(xiàn)訂單的遍歷，那么跟蹤代碼就應該看對訂單的ID有無校驗？
優(yōu)惠券這里沒開放，最后就是積分功能，那么會不會存在使用積分付費，然后由于校驗不完整，使用負積分付費從而導致積分反增不減這樣的漏洞出現(xiàn)？
首先測試來修改用戶的“基本資料”，這里可以fuzz一下后臺語句，可以修改為woaini”<>，然后看回顯，，其實就可以大致猜出后臺代碼。
修改完可以看到沒有任何的顧慮，那么這里的存儲型xss石錘！
雖然這里是表單，但是后臺管理員查看用戶信息時卻不需要閉合表單，因此直接插入xss語句即可~
這里再來找一下源代碼，看看到底怎么寫的！
可以看到這里都是直接request獲得，并沒有任何過濾，看代碼的更大陰謀就是看看這里的sql語句怎么實現(xiàn)的，首先我們是登錄用戶，然后姓名、地址、電話什么的都沒輸錯，因此進入最后一個else語句。
flag=ss.addAddress(user.getId(), name, tel, address); //這里是用來實現(xiàn)sql語句的，跟進！-----------------------------------*分割線*---------------------------------------------------------- public Integer addAddress(Integer userId, String name, String tel, String address) { Object args[] = { name, tel, address, userId }; String sql = 'insert into user_address (user_address_name,user_address_tel,user_address_content,user_address_user) values(?,?,?,?)'; Serializable flag = jdbc.insertBackId(sql, args); /*采用預編譯*/ jdbc.close(); return Integer.valueOf(flag.hashCode()); }可以看到這里的sql語句采用的是預編譯，因此sql注入漏洞可能不存在，但是預編譯最怕的就是字符串的直接拼接，這里在sql語句里看了全部的sql語句，并不存在這樣的案例，因此sql這條路可能走到底了。
不過不用慌，繼續(xù)審計！下面來重點關注這個訂單功能，這是整個cms的核心所在！
這里由于不存在數(shù)量這樣的參數(shù)，因此修改數(shù)量為負數(shù)這樣的情況并不存在，實際上是從session來獲取用戶的積分，因此積分上應該也不存在漏洞，最后只能提交訂單然后抓包看參數(shù)進行代碼溯源~
這里由于都是通過id這樣的參數(shù)來進行傳遞，那么可以在審計的過程中留意id是否判斷所屬用戶，也就是越權的問題，最重要的可能就是這里的price參數(shù)有無檢查！
然后全局搜索，找到可疑函數(shù)，確定為添加訂單的函數(shù)。
public void addGoodsOrder(HttpServletRequest request, HttpServletResponse response)throws ServletException,IOException{ response.setContentType('text/html;charset=UTF-8'); HttpSession session = request.getSession(true); Object ordinary_user=session.getAttribute('ordinary_user'); String tem_store_id=request.getParameter('store_id');//門店id String price=request.getParameter('price'); String tem_address_id=request.getParameter('address_id'); String tem_goods_id[]=request.getParameterValues('goods_id'); String content=request.getParameter('content'); String serviceDate=request.getParameter('serviceDate'); Integer store_id=null; Integer address_id=null; Integer goods_id=null; Integer order_id=0; ……………略去部分代碼…………… if(ordinary_user==null){ json='{\'tip\':\'請登錄之后再操作\',\'status\':500}'; }else{ User user=(User)ordinary_user; //這里添加訂單信息 //order_id=ss.addGoodsOrder(2, 1, 1, 1,serviceDate, null, content, user.getId(),null, store_id, null, price, 1, 1, address_id, 2,'3', user.getId().toString(), null, goods_id, 1,''); if(order_id>0){ if(tem_goods_id.length>0){ for(int i=0;i這里我們需要跟進這個ordinary_user，到這里price這個參數(shù)都沒有任何過濾，是通過直接request請求獲取的。
這里就不截取代碼了，可以明顯看到這里的price參數(shù)依然沒有進行任何校驗，因此到這里我們可以最終判斷，這個price參數(shù)可以進行任意修改！
這里修改參數(shù)有兩種方法，第一種就是直接抓包修改即可，因為無任何校驗機制，所以可行。
第二種則是修改頁面的表單參數(shù)，這里后來查看付款源碼，發(fā)現(xiàn)會在頁面中hidden傳過來的參數(shù)。
這里通過修改頁面源碼里的value值也行~
進入到個人中心，這里的訂單信息獲取是通過session來獲取用戶，因此也就無法獲取他人的訂單信息。
不過這里有幾個功能，第一個就是取消訂單的功能，那么對訂單編號是否進行了用戶歸屬的檢驗呢？讓代碼來告訴我們！
這里會將輸入的訂單與用戶自身的訂單號來進行一個匹配，若匹配成功才會取消訂單信息，因此這里不存在越權的漏洞！
那么前臺的代碼審計就告一段落，后臺的代碼就先不看了~
這篇文章重點是講解一下筆者的JAVA代碼審計的思路與方法，希望拋磚引玉，能夠有越來越多高質量的JAVA代碼審計文章的出現(xiàn)~
上述如有不當之處，敬請指正！
聯(lián)系客服
