最近在审计java的CMS，跟着文章进行nday审计，找准目的newbee-mall Version1.0.0（新蜂商城体系），并跟着网上文章进行审计：
https://blog.csdn.net/m0_46317063/article/details/131538307
[img=720,367.938]https://m-1254331109.cos.ap-guangzhou.myqcloud.com/202410101641859.png[/img]
下载唯一的版本，且源码README中版本也对的上，但没想到nday全部复现失败，但在一番审计后找到了一个新的漏洞点：ssrf，且在前台可以被用户触发。
失败的man与nday：
失败的sql注入漏洞：
（此漏洞原本可以在前台与后台进行sql注入攻击）
分析文章中有两sql注入漏洞，是由于引入mybatis依赖导致，但在我下的版本中根据关键字符${找不到任何的注入点，颠末与分析文章对比发现所有注入点全部由${改成了#{由此完成修复。
[img=720,285.7142857142857]https://m-1254331109.cos.ap-guangzhou.myqcloud.com/202410101641860.png[/img]
失败的权限绕过：
（此漏洞原本可以在admin登录后台通过/;/admin/test完成权限绕过）
复现文章写到以request.getRequestURI()获取路径获取路径后再进入if判定：
[img=720,188.8139281828074]https://m-1254331109.cos.ap-guangzhou.myqcloud.com/202410101641862.png[/img]
但我下载的版本进行了修复：将获取前端传输的路径方法改为了：getServletPath()从而完成修复。
两种方法的不同详细分析可以参考如下文章：
https://forum.butian.net/share/3730
失败的越权漏洞：
（此漏洞原本可以根据传入的id参数越权修改他人信息。）
定位到详细代码：
[img=720,411.5]https://m-1254331109.cos.ap-guangzhou.myqcloud.com/202410101641863.png[/img]
此处代码与复现文章一样，都是先创建一个NewBeeMallUserVO对象，再通过是否为空判定信息修改是否成功。
【----资助网安学习，以下所有学习资料免费领！加vx：dctintin，备注 “博客园” 获取！】
① 网安学习成长路径头脑导图
② 60+网安经典常用工具包
③ 100+SRC漏洞分析报告
④ 150+网安攻防实战技术电子书
⑤ 最权威CISSP 认证考试指南+题库
⑥ 超1800页CTF实战技巧手册
⑦ 最新网安大厂面试题合集（含答案）
⑧ APP客户端安全检测指南（安卓+IOS）
真正修改信息的代码在updateUserInfo方法内里，于是跟进该方法实现处：
[img=720,367.78979907264295]https://m-1254331109.cos.ap-guangzhou.myqcloud.com/202410101641864.png[/img]
[img=720,440.91603053435114]https://m-1254331109.cos.ap-guangzhou.myqcloud.com/202410101641865.png[/img]
发现跟到了接口，于是我们继续跟进，找该接口的实现类：
[img=720,507.90697674418607]https://m-1254331109.cos.ap-guangzhou.myqcloud.com/202410101641866.png[/img]
跟进到如下类，找到详细实现的代码块：
[img=720,440.52015604681407]https://m-1254331109.cos.ap-guangzhou.myqcloud.com/202410101641867.png[/img]
复现文章代码在进入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的发现：
登录后台，点击修改或者添加商品：
[img=720,386.1198738170347]https://m-1254331109.cos.ap-guangzhou.myqcloud.com/202410101641868.png[/img]
随意传入图片后点击生存并抓包。
[img=720,74.28571428571429]https://m-1254331109.cos.ap-guangzhou.myqcloud.com/202410101641869.png[/img]
将POST数据包如上两个参数修改为dnslog地址，放包，在商城前台搜刮该商品名称。
[img=720,391.5390686661405]https://m-1254331109.cos.ap-guangzhou.myqcloud.com/202410101641871.png[/img]
点击访问，dns平台出现记录。
[img=720,331.26588713777323]https://m-1254331109.cos.ap-guangzhou.myqcloud.com/202410101641872.png[/img]
漏洞代码分析：
先看看商品信息存储过程：
根据接口定位代码块：
[img=720,503.9010989010989]https://m-1254331109.cos.ap-guangzhou.myqcloud.com/202410101641873.png[/img]
可以发现在接受参数后进行是否为空判定后进入了核心方法updateNewBeeMallGoods，跟进：
[img=720,390.14778325123154]https://m-1254331109.cos.ap-guangzhou.myqcloud.com/202410101641874.png[/img]
跟到接口后再找到接口实现类，最后定位到更新信息代码块。
可以看到，仅仅对传入参数值进行为空判定和相同判定后，便调用set方法进行存储。
接下来再看看商品信息调用代码链。
根据触发漏洞的数据包接口定位代码块：
[img=720,418.5365853658537]https://m-1254331109.cos.ap-guangzhou.myqcloud.com/202410101641875.png[/img]
此处代码根据传入goodsid参数，将商品渲染到前端，也就是搜刮商品后，见到商品那刻触发漏洞。
对接受goodsid参数是否></strong>
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 | 
