0x1 Actuator泄露403绕过
在渗透测试中，经典的登录框往往是起点。通过观察网络请求，经验丰富的测试者通常会快速锁定类似 /prod-api/ 这样的接口，这是 Spring Boot 应用端点泄露的高频路径，其下往往存放着 /env、/heapdump 等敏感端点。
使用目录扫描工具进行探测时，所有相关路径均返回403状态码，这通常意味着后端配置了过滤器（Filter）进行权限校验。若返回404，则可能路径有误，例如需要添加或删除某一层路径前缀。因此，当前的核心问题是如何绕过这个403限制。
访问相关路径时，浏览器会显示一个由 nginx/1.24.0 返回的“403 Forbidden”错误页面，同时终端扫描日志也确认了多个路径（如 /prod-api/nacos/actuator/heapdump）均返回403。
绕过思路在于对路径中的特定字符进行编码。以 actuator 端点为例，其中的字母 o 属于URL中的普通字符，标准URL编码不会对其进行处理。但我们可以使用其ASCII码的十六进制表示进行强制编码。
在URL编码中，字符 o 的ASCII码十进制值是111，转换为十六进制是 6F。因此，其编码形式为 %6F。使用在线的编码解码工具可以验证这一点：在“解码”模式下，输入 %6F，输出结果为 o。
手动计算ASCII码转换较为繁琐，可以借助AI或专用工具快速获取字符的编码值。例如，查询可知字符 r 编码后为 %72，同样可以通过工具验证解码正确。
将这一原理应用于实际路径，把 actuator 中的 o 替换为 %6f，构造出新的路径：/prod-api/actuat%6fr/。使用此编码后的路径进行访问，成功绕过403限制，发现了 heapdump、env、nacosconfig 等多个敏感端点信息，从而打开了新的攻击面，例如可以进一步测试 gateway 路由是否存在RCE漏洞。
https://xxxxxx.com.cn:8088/prod-api/actuat%6fr/ ------ 成功访问根目录
https://xxxxxx.com.cn:8088/prod-api/actuat%6fr/env ------ 成功访问
https://xxxxxx.com.cn:8088/prod-api/actuator/env ------ 403 (未编码)
访问 actuat%6fr 目录后，返回的JSON数据展示了大量的端点信息，例如：
{
"templated": false,
},
"nacosconfig": {
"templated": false
},
...
"metrics": "/actuator/metrics",
"metrics-requiredMetricName": "/actuator/metrics/{requiredMetricName}",
...
}
后续访问这些具体端点（如 /actuat%6fr/env）时，也必须使用编码后的路径，否则仍会返回403。
除了手动编码，也可以利用一些综合渗透工具来完成此操作。例如，在 poc2jar综合利用工具 的界面中，在编码输入框内填入 actuator，然后点击“URL编码”按钮，即可得到 %61%63%74%75%61%74%6f%72 的结果，其中 %6f 即对应字母 o。
0x2 小程序Host渗透后台
在对某小程序进行测试时，常规的鉴权绕过、注入、逻辑漏洞均未发现。随即转变思路，尝试寻找其对应的Web后台管理地址，以开辟新的攻击面。
小程序的后台管理页面可能位于其他子域名下，也可能就在小程序宿主（Host）域名的其他目录中。首先尝试直接访问小程序的Host域名根路径，页面正常回显。
在确认根路径可访问后，使用目录扫描工具对该域名进行递归探测，尝试发现后台地址。
扫描过程较为顺利，工具很快 Fuzz 出了第一层前置目录 /manage。访问此目录后，直接跳转到了后台登录地址。
https://city.xxxx/manage/ ------> 跳转至 https://city.xxxxx/manage/login?redirect=/
这带来了新的测试点，如弱口令、未授权访问、JS接口泄露等。
然而，渗透测试者常常会陷入“先入为主”的思维定式：一旦找到目标（后台地址），就可能忽视其他信息。耐心审查扫描工具输出的完整结果至关重要。在本案例中，工具随后又发现了第二个前置目录 /backend。访问此目录同样会跳转到一个全新的后台系统。
https://city.xxxxxxxx/backend/ ------> 跳转至 https://city.xxxxxx/backend/login?redirect=/
至此，我们发现了同一域名下的两套独立后台系统。
回到第一个 /manage 目录的系统。对于这种隐藏在深层目录的后台，管理员设置密码时可能相对松懈。经过简单的弱口令测试，成功使用 admin/123456 进入后台。
登录后，可以查询到小程序内所有用户的实名信息（三要素）并控制其账户余额，造成了严重的信息泄露和业务安全风险。
在第一个后台系统中进行功能测试时，发现了一个“城市合伙人”管理模块。这恰好与第二个后台系统的名称相关联。推测第二个系统的账号很可能就是手机号。利用从第一个后台获取到的合伙人手机号，尝试配合默认密码（如123456）进行登录，成功拿下了第二个后台系统。这再次印证了渗透测试的本质之一：信息收集。
0x3 Shiro框架反序列化与容器RCE
在一次针对大量子域名资产的渗透项目中，使用指纹识别工具发现目标存在 Shiro 框架。随即使用反序列化漏洞利用工具进行测试。
在工具中输入目标地址，很快便爆破出了AES加密密钥（key）。密钥被快速爆破出来（约2秒），暗示目标可能运行在Docker容器等标准化环境中。
继续利用工具爆破可用的利用链（Gadget Chain），发现存在 CommonsBeanutilsString 这条链。这意味着可以直接在工具的功能区调用命令执行，或生成内存马（如冰蝎马）连接。
为了确认环境是否为容器，执行了查看cgroup信息的命令：
cat /proc/1/cgroup
从返回的信息中可以清晰看到 docker/ 路径，确认当前为Docker容器环境。
即使是容器环境且无法逃逸，也并非没有利用价值。该容器很可能与内网其他网段（如 172.16.0.0/12、10.0.0.0/8 等）相通。后续通过注入内存马并建立连接后，可以进行内网横向移动。
有些 Shiro 框架站点，指纹识别工具可能无法有效发现。只有在测试请求和响应中，通过观察 RememberMe 字段才能识别。推荐使用被动扫描插件（如 BurpShiroPassiveScan），它能够有效识别Shiro框架并辅助进行 Shiro-721 等漏洞的检测。安装插件后，只需在配置文件中补充常见的Shiro密钥，即可在测试过程中自动识别，不错过任何潜在目标。
0x4 JS接口泄露与同域名站点接口复用
面对一个基于 Vue 框架的登录页面，首先使用浏览器插件提取前端 JavaScript 文件中的API接口。提取到的接口路径通常需要加上推测的前置目录（如 /api）才能构成完整的请求。
对构造的接口进行爆破后，仅发现一处信息泄露，且泄露的信息量（如姓名、电话）较少，其中姓名还被 Unicode 编码。这时可以通过控制页面参数（如页码、每页数量）来尝试获取更多数据。以下是常用的页码组合参数，可用于 Fuzz：
/api/users/error_list?page=1&limit=10000
page=1&size=10000
page=1&page_size=100
pageSize=10&pageIndex=1
{"pageNum": "1", "pageSize": "100"}
{"pageNo": 1, "pageSize":100}
{"pn":1, "size":10}
通过添加 ?page=1&limit=10000 参数，成功从一个接口中获取了近7000条用户信息，危害显著提升。
除了提取常规JS，还可以进一步提取异步加载的 chunk-vendors.js 等文件，在其中发现了另一个信息泄露接口：
/api/test/test_user_list?page=1&limit=10000
通过资产测绘平台，发现了同一主域名下的另一个新站点。两者功能相似。可以利用“同域名站点接口复用”的技巧进行测试。即将已挖掘站点（test.xxx.com）上发现的敏感接口，直接应用于新发现的站点（xxx.com）进行访问。
# 新站点
xxx.com
# 已挖掘站点
test.xxx.com
# 接口复用测试
/api/test/test_user_list?page=1&limit=10000 # 在新站点上复用成功
/api/users/error_list?page=1&limit=10000 # 在新站点上复用失败
同时，也需要针对新站点本身进行接口提取和测试，可能会发现独有的泄露接口，例如：
/api/users/search?page=1&limit=10000
0x5 业务功能点注入与越权文件覆盖
在测试业务功能时，除了关注JS接口，对具体功能点的深度测试同样重要。进入一个站点并注册登录后，应代理所有流量，完整浏览页面功能，然后在历史请求中仔细筛查可能出问题的接口。
在一处显示列表的功能中，发现 tagId 参数。尝试注入单引号或双引号均返回500错误。转而测试数字型注入，使用 and 1=1 和 and 1=2 进行布尔判断，发现页面返回存在差异，证实存在SQL注入漏洞。
tagId=119 and 1=1 # 正常返回
tagId=119 and 1=2 # 返回500或异常
这是一个无回显的注入点，可以通过布尔盲注或时间盲注进一步利用。例如，利用 if 函数结合 exp() 报错来判断数据库名长度：
tagId=119 and if(length(schema())>7,exp(999),1) # 若为真则报错
tagId=119 and if(length(schema())=7,exp(999),1) # 确定长度为7
确定长度后，使用 substr() 函数逐位爆破数据库名：
tagId=119 and if(substr(schema(),1,1)='a',exp(999),1)
最终爆破出当前数据库名为 chatgpt。
在同一站点的其他功能点，被动扫描提示 modeIType 参数存在 XPATH 报错注入。这是一个典型的报错注入场景，使用相应Payload即可直接爆出数据库名：
modeIType=video' and extractvalue(1,concat(char(126),database())) and '
后续在该站点还发现了多处SQL注入点。
在测试头像上传功能时，发现图片上传至对象存储，且响应包中回显了上传后的文件名。测试发现，文件名和存储目录路径均可控。通过构造上传请求，可以实现对已存在的同名文件（如网站图标）的覆盖。
虽然直接覆盖特定用户文件难度大，但发现网站内的公共静态图片也存储在同一个桶内。通过上传恶意 SVG 文件，并将上传路径指定为网站图标的目录路径，成功覆盖了网站图标，证明了漏洞的危害性。测试后应使用备份的原始图片进行还原。
0x6 API接口前置目录混淆与Actuator信息泄露
面对另一个 Vue 站点，使用插件提取接口后尝试访问，发现全部被重定向回首页。这通常意味着存在未识别的前置目录。通过触发登录功能，得到一个登录接口：/api/sys/login。尝试以此为基础爆破其他接口，结果大量接口返回401（缺少token）或502错误。
进一步分析提取到的接口列表，发现其中包含诸如 /gcwms-boot/sys/login 这样的路径。对比可知，/gcwms-boot/ 才是真正的前置目录，它对应着之前猜测的 /api。因此，需要将提取到的所有接口中的 /gcwms-boot/ 全局替换为 /api，再进行测试。
此外，对于 Vue + Spring Boot 的架构，使用目录扫描或被动扫描插件常能发现 actuator、swagger、druid 等经典信息泄露端点。在本案例中，被动扫描插件就发现了 /actuator 路径。
直接访问 /api/actuator，页面显示了大量的端点链接，但其中并未直接列出 /env 或 /heapdump。在众多端点中，/httptrace 容易被忽视。该端点会记录HTTP请求的追踪信息，包括请求头、响应状态等，有时会包含最新的鉴权Token（如JWT）。
访问 /api/actuator/httptrace，在返回的JSON数据中，查找最新的请求记录，从中提取到了有效的 x-access-token：
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE3NjA5Mjk4MjAsInVzZXJuYW1lIjoiYWRtaW4ifQ.PuGa-Fo5o7N0mH2Dxmllov3XpLyJX5oDNGrJT-8fkz8
将此Token添加到请求头中，重新遍历之前处理好的业务接口，成功获取到大量业务数据泄露，包括联系人列表、供应商信息等，证明漏洞危害。
0x7 民生业务场景中的互联网信息收集思路
在针对某城市水务公司的众测项目中，Web端资产大多需要统一认证账号。转向小程序资产后，发现即使通过微信登录，仍需绑定具体的居民用水户号才能测试核心功能。
为此，开展了深入的互联网公开信息收集。在抖音、小红书等社交媒体平台，使用实用性的关键词进行检索：
xxx市 水费
xxx市 水费缴纳
xxx水费 太贵了
在众多用户分享的帖子中，耐心寻找可能泄露的户号、姓名片段。最终，在一个帖子中找到了包含不完整户号和部分姓名的截图。
随后，通过社工手段（例如关联该用户在平台的其他信息、评论区互动等），最终结合其他工具获取到了完整的用户三要素（姓名、电话、身份证号）。有了完整的户号和姓名，成功在小程序绑定账号，并后续测试发现了越权访问等漏洞。
这种思路适用于水电煤、医疗、教育等涉及大量居民日常业务的行业。公开的社交媒体已成为一个巨大的、未被充分重视的信息源，善用搜索技巧往往能为渗透测试打开突破口。
参考资料
[1] 【攻防渗透集锦】漏洞组合拳与JS攻击面的博弈, 微信公众号：mp.weixin.qq.com/s/URG8rVQDIpjE0cR3OI5xFQ
版权声明：本文由 云栈社区 整理发布，版权归原作者所有。
发表于 昨天 16:27
|
查看: 8|
回复: 0
