一次曲折的漏洞测试之旅

0x01 前言

这是一次“曲折”的漏洞测试之旅，主要是对我来说曲折，记录一下，给自己做个回顾，也希望能给大家一点帮助。本次属于授权测试，任何未授权的测试都是违法行为！

0x02 测试

01 初步测试

给到的目标是一个域名，访问域名时抓包如图

然后会自动跳转到sso统一认证平台

看到接口中的/api，习惯性的尝试/api/v1/api-docs

不存在，继续尝试/v2/api-docs

还是不存在，再尝试一下/v3/api-docs

看到停顿了一会和Waiting，我大概猜到应该是有东西的，果不其然

这里由于我是单个目标，所以测试比较悠哉，如果多个目标还是建议使用扫描器扫目录

既然存在这个那必然存在actuator接口，访问一下

很可惜，接口少得可怜，没法利用，随后转战api接口

用正则将接口提取出来，用burp跑一下

也有跑出几个未授权访问的接口

但是并不能很好的利用，比如其中一个根据id获取oss下载连接的接口

可以看到id的取值类型为java.lang.Long，尝试了按数字顺序爆破，没有任何反应，我大概就猜到不是顺序排列的id了，后面也确实印证了我的猜想

我看了一下，long类型最长可以有十九位，如果要爆破，得到地老天荒，可能网站关了，还在爆破。

现在我的目的就是扩大危害，因为如果只是一些简单的未授权，可能有危害，但是又像软绵绵的拳头打在身上，让人不痛不痒。

随后我又对其他几个未授权接口进行了测试，均未果，要么是500，要么是只展示一些介绍信息。

02 “曲折”的开始

下面就是我“曲折”的开始了，当我把所有接口都测了个遍之后，并没有发现有危害的点，然后我突然想到了登录接口

提示Request method 'GET' not supported，GET不支持，那咱就POST嘛

提示缺少请求体，那咱们就构造请求体

果然，提示用户密码不能为空，这里我是盲猜username/password字段

字段是对上了，但是好像没有那么简单，报错了，提示不能解密块数据，看来是需要加密后传输

这里由于访问会直接跳转sso认证平台，所以前端界面渲染不出来，尝试卡在跳转前界面上，搜索加密关键字，但是没有搜到，只搜到了一条

这个时候有些小伙伴可能会卡住了，没有前端界面给我们触发debug调试，js文件中也没发现encrypt定义的函数，该怎么办呢？

由于我是已经独木桥走了一半，只能继续往前了，所以我将索引js文件保存到本地，分析

搜索加解密相关关键字，发现一个都没有

无奈只能转变思路，找登录相关关键字“login”

发现导入了另一个index开头的js文件，然后将它下载回本地，继续分析

还是搜索login关键字，这次有了一些发现

发现了加密函数At，对用户名和密码进行了加密，然后登录

我们来看看At是个啥函数

可以确定是加密函数没跑了，而且key使用的硬编码

由于代码又臭又长，加上本人并不擅长加解密这块，所以我并没有打算硬刚加密算法，退而求其次，我直接把js代码照搬到本地，俗话说的好，打不过就加入，我本地还原，调用还不行吗

这里有一点要注意，就是该项目是使用ES6 模块语法编写的 JavaScript，所以我们需要在项目根路径，创建一个package.json，内容如下

这里不得不说一句，chatgpt真香，哈哈

之后编写一个js文件导入调用函数就行

这里也遇到了一些小问题，一个就是一些对象找不到的问题，类似windows、document之类的，这里我的解决方法简单粗暴，直接删除就行，我需要的是加密相关代码，这些对象没什么用

当我把报错解决之后，代码就跑起来了

现在可以生成密文了，但是还有一个小问题，就是【UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "请在public文件夹下 添加serverConfig.json配置文件".】，这里记录一下是如何解决的

因为虽然生成了密文，但是生成之后就抛出异常了，当我想批量加密的时候，其他代码块就无法执行了，比如写入操作

一开始搜索了一下，没找到满意的解决方案，还得是chatgpt，几行代码解决

解决报错之后就可以正常加密读写文件了

加密问题解决了，但是又有新的问题出现了，这他喵的还需要验证码

回顾一下前面的js代码，好像确实有验证码这个参数

没办法，只能看看验证码怎么来的，能不能绕过

通过之前的接口测试发现，有一个接口为/captchaImage，请求返回结果如下

嗯，没跑了，肯定是这里生成的验证码，这里的验证码是图片的base64编码，我们使用如下格式在浏览器打开就能看到了 data:image/png;base64,图片base64

好了，验证码有了，uuid也有了，那就来看看能不能成功请求吧

提示账号不存在，应该没问题了，再重放一次看看呢

不幸的消息，验证码只能使用一次，后面经过测试，应该是uuid只能使用一次，没匹配上就G了，真是屋漏偏逢连夜雨 ，船迟又遇打头风啊！

但是都到这了，放弃是不可能放弃的了，只能硬着头皮往前走

03 暴力猜解

经过多次获取验证码，我发现了一个小规律，就是十次以内，验证码计算得出的结果，多数都在0~9这样子

由于验证码识别较为麻烦，而且识别之后还得做一次数学运算，我是没那个精力去折腾了，所以退而求其次，发现规律，验证规律，运用规律！

我就让gpt帮我写了一个从0-9依次循环获取uuid并和验证码组合成请求体，然后对单个用户名进行暴力猜解，相当于一个用户名需要请求10次，在这种恶劣的环境下，我觉得算不错的了，只要能出货，付出点时间也是值得的

但是！事情的发展总是事与愿违，服务器都快跑冒烟了，也没跑出个用户来，我也是头一回遇到top几百砸下去之后，没有一点水花的，就是连用户名都没猜解到，更别说密码猜解了

说实话，此刻我的心态是有点崩溃的，绝望的种子已经在慢慢的生根发芽

04 峰回路转

但是，好在天无绝人之路，上天不会辜负一个努力的人，我突然想到了还有一个方法没试过，那就是鉴权绕过。一开始因为先入为主，看到spring boot，看到接口泄露，我的关注点就都在接口测试上面了，反而忽略了更为简单的鉴权绕过

由于有段时间没复习相关知识了，所以搜了一下，找到了一篇先知的文章，我会放在参考链接里

尝试了绕过方法，问号没有过

又试了一下斜线，返回操作成功

我嘞个豆！

这时，我是又高兴，又气愤。高兴的时，我绕过鉴权了，高危到手。气愤的是，为什么没有一开始就想到绕鉴权！

平复完心情之后，就是一波收割了，证明危害即可。

0x03 总结

有的时候我们往往会将一件简单的事情，复杂化，但其实回过神来发现并没有那么复杂。本次文章也是提醒自己不要固化思维，但我也挺享受测试的过程的，所有的尝试都是对自己能力的锻炼和提升，与君共勉。

0x04 参考文章

JAVA代码审计-SpringSecurity权限绕过分析（https://xz.aliyun.com/t/13235）

原文始发于微信公众号（伟盾网络安全）：一次“曲折”的漏洞测试之旅