最近在審計java的CMS，跟著文章進行nday審計，找準目標newbee-mall Version1.0.0（新蜂商城系統），並跟著網上文章進行審計：
https://blog.csdn.net/m0_46317063/article/details/131538307
下載唯一的版本，且原始碼README中版本也對的上，但沒想到nday全部復現失敗，但在一番審計後找到了一個新的漏洞點：ssrf，且在前臺可以被使用者觸發。
失敗的man與nday：
失敗的sql注入漏洞：
（此漏洞原本可以在前臺與後臺進行sql注入攻擊）
分析文章中有兩sql注入漏洞，是由於引入mybatis依賴導致，但在我下的版本中根據關鍵字元${找不到任何的注入點，經過與分析文章對比發現所有注入點全部由${改成了#{由此完成修復。
失敗的許可權繞過：
（此漏洞原本可以在admin登入後臺透過/;/admin/test完成許可權繞過）
復現文章寫到以request.getRequestURI()獲取路徑獲取路徑後再進入if判斷：
但我下載的版本進行了修復：將獲取前端傳輸的路徑方法改為了：getServletPath()從而完成修復。
兩種方法的不同具體分析可以參考如下文章：
https://forum.butian.net/share/3730
失敗的越權漏洞：
（此漏洞原本可以根據傳入的id引數越權修改他人資訊。）
定位到具體程式碼：
此處程式碼與復現文章一樣，都是先建立一個NewBeeMallUserVO物件，再透過是否為空判斷資訊修改是否成功。
【----幫助網安學習，以下所有學習資料免費領！加vx：dctintin，備註 “部落格園” 獲取！】
① 網安學習成長路徑思維導圖
② 60+網安經典常用工具包
③ 100+SRC漏洞分析報告
④ 150+網安攻防實戰技術電子書
⑤ 最權威CISSP 認證考試指南+題庫
⑥ 超1800頁CTF實戰技巧手冊
⑦ 最新網安大廠面試題合集（含答案）
⑧ APP客戶端安全檢測指南（安卓+IOS）
真正修改資訊的程式碼在updateUserInfo方法裡面，於是跟進該方法實現處：
發現跟到了介面，於是我們繼續跟進，找該介面的實現類：
跟進到如下類，找到具體實現的程式碼塊：
復現文章程式碼在進入if判斷前只有一行程式碼，並且程式碼邏輯是從前端傳入的id值進行資訊修改，但可以看到我下載的程式碼有兩行：
NewBeeMallUserVO userTemp = (NewBeeMallUserVO)httpSession.getAttribute(Constants.MALL_USER_SESSION_KEY);
首先透過http.Session獲取當前使用者，再賦給建立的userTemp物件。
MallUser userFromDB =mallUserMapper.selectByPrimaryKey(userTemp.getUserId());
再從userTemp物件中獲取id值進行資訊修改，而非從前端請求中獲取引數id的值，來完成漏洞修復。
0day的發現：
登入後臺，點選修改或者新增商品：
隨意傳入圖片後點選儲存並抓包。
將POST資料包如上兩個引數修改為dnslog地址，放包，在商城前臺搜尋該商品名稱。
點選訪問，dns平臺出現記錄。
漏洞程式碼分析：
先看看商品資訊儲存過程：
根據介面定位程式碼塊：
可以發現在接受引數後進行是否為空判斷後進入了核心方法updateNewBeeMallGoods，跟進：
跟到介面後再找到介面實現類，最後定位到更新資訊程式碼塊。
可以看到，僅僅對傳入引數值進行為空判斷和相同判斷後，便呼叫set方法進行儲存。
接下來再看看商品資訊呼叫程式碼鏈。
根據觸發漏洞的資料包介面定位程式碼塊：
此處程式碼根據傳入goodsid引數，將商品渲染到前端，也就是搜尋商品後，見到商品那刻觸發漏洞。
對接受goodsid引數是否<1判斷後進入取商品資訊程式碼。
跟進getNewBeeMallGoodsById方法，找到方法介面後再找介面實現類，再找方法：
發現goodsid引數傳入selectByPrimaryKey方法。
該方法透過資料訪問物件（DAO）goodMapper呼叫，且在方法最前處由NewBeeMallGoodsMapper對其定義：
全域性搜尋，找到對應xml檔案：
發現透過id引數對資料庫操作，取出goodsCoverImg與goodsCarousel引數。
回到最先前的類：
此時goods物件已經獲取商品相關引數值。
再進入if判斷商品是否上架，上架則進入下一輪程式碼，將商品資訊封裝為檢視模型，找到NewBeeMallGoodsDetailVO類，發現只接受了goodsCoverImg引數，也就是先前抓包修改處只用修改該引數即可：
最後返回檢視名稱"mall/detail"，表示渲染商品詳情頁面：
由於儲存時未做任何過濾，進行檢視層渲染時直接拿出goodsCoverImg引數放到前端，導致使用者一旦訪問商品便觸發該漏洞。
更多網安技能的線上實操練習，請點選這裡>>