0  -  http://xxx.com/xxx 或 https://xxx.com/xxx
1  -  /aaa/bbb

/data_marxxx
/cloud/user_xxxxx/user/list
/cloud/order/
/process
/process/hanxxx
/process/addCounterxxxxxx
/cloud/asset/authxxxxx/search

Spring框架是Java平台上的一种开源应用框架，提供具有控制反转特性的容器。尽管Spring框架自身对编程模型没有限制，但其在Java应用中的频繁使用让它备受青睐

这说明：还有一层目录才能够到达SpringBoot的目录！

信息收集到达这一步后，瞬间燃起来对接下来挖掘漏洞的激情，已有的信息收集和多年渗透测试经验让我觉得他一定是有漏洞的。

拨开迷雾见光明

既然已经想明白了/data_marxxx目录实际是存在的，并且它的下一层目录就是SpringBoot，于是访问/data_marxxx并抓取GET数据包，丢在Burpsuite中进行二级目录爆破。

放入目录字典进行Fuzz测试，这里选择使用Burpsuite的原因是，SpringBoot目录的访问报错，状态码依然是404，而使用Burpsuite的返回值Length长度，可以轻松筛选出是否成功爆破到了SpringBoot目录。

爆破URI时，需要在Burpsuite中勾掉默认的URLEncode选项：

接下来就是静等结果了，一般爆破目录不附带恶意Payload的话，WAF基本不会拦截的，除非有防DDOS、CC攻击的设备，线程调小也可以避免被Ban自己的IP。

功夫不负有心人，成功爆破到了状态码为404的SpringBoot报错页面！

拼接访问：http://***.com/data_marxxx/cloud/

果然是你，我亲爱的SpringBoot老朋友。

原本以为隐藏的这么深的SpringBoot页面，肯定会有SpringBoot的信息泄露漏洞，运气好的话还可能有代码执行RCE，于是使用SpringBoot敏感目录扫描：

但是使用SpringBoot敏感目录字典扫描后发现，一个也没有！

就连接口文档swagger-ui.html也删除的干干净净。

那这样的话，就连SpringBoot信息泄露都没有了。

就在我垂头丧气的时候，突然灵光一闪想到了一开始在JavaScript文件中获取到的另外几个路径。

/cloud/user_xxxxx/user/list
/cloud/order/
/process
/process/hanxxx
/process/addCounterxxxxx
/cloud/asset/authxxxxxxxx/search

cloud这不是你吗？？？直接拼接访问：

http://***.com/data_matxxx/cloud/user_xxxxx/user/list

这特喵的，直接当场跪了！

第一个漏洞：未授权调用系统接口查询全部用户数据。

之后就顺利多了，拼接/data_marxxx/cloud/order，后面再跟一个ID参数，回显了如下数据。

需要在Cookie加入user_code参数，而user_code参数，存在于第一个漏洞的回显数据中。

并且，只需Cookie就可以查询数据，并且数据编号可以全部遍历。

于是，第二个漏洞产生：越权查询全部系统流程数据。

回首总结

此漏洞的挖掘到这里也可以结束了，但是回过头来才发现，一开始筛选出6个接口时，如果更细心、更脑洞大开一点的话，或许直接拼接也不用走那么多弯路。

并且，后来在审计JavaScript的代码逻辑中，细心一点是可以看出地址拼接的逻辑的，如下：

关键代码为：

H="/data_marxxx"
z.get("".concat(H,"/cloud/order/")

其实已经可以发现data_marxxx与cloud拼接了，但是面对如此复杂并且杂乱的JavaScript代码，又有几个人能静下心来慢慢审计呢？

一句话概括此次挖掘漏洞过程：细心到极致方可不错失漏洞。

希望这个简单的漏洞挖掘过程，能给大家带来一些挖洞思路~

谢谢大家！