免责声明：
本文章内容仅供网络安全技术人员学习交流，旨在提升网络安全防护意识与技能。文中所涉及的技术、工具及方法，严禁用于任何非法目的或未授权的网络攻击。
未经授权入侵计算机系统、窃取数据或干扰网络正常运行均属违法行为。因读者滥用本文章内容所导致的任何直接或间接法律后果及损失，均由使用者本人承担，与文章作者及发布平台无关。
登录框起手，一般测的流程这里就不讲了，而且因为部分原因也比较难操作
URL为/#/login,典型的单页应用（SPA）前端路由,看一眼插件：
为VUE的hash模式：
#号后面的内容变化，浏览器不会向服务器发送新的请求，完全由前端（Vue）在浏览器端控制页面切换。这种模式部署非常简单，不需要服务器做特殊配置，直接放到 Nginx/Apache 的静态目录下就能跑。
所以在burp里面抓到的包是不会拼接/#/login路径的：
并且直接重放器里面发送显示的是304，这里其实还可以讲讲URI语法结构问题：
该规范明确规定，fragment信息在向源服务器发送请求时不得包含在请求行或请求头中，因为服务器只需提供资源本体，无需也通常无法理解片段所指向的二级子状态
下面就是304这一块，说起来之前都没碰到过304，还是挖太少了：
304（未修改） - 自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。
触发304的必要条件有两个：
- 请求中必须携带有效的条件头域，通常为
If-Modified-Since或If-None-Match - 服务器必须拥有对该资源的缓存验证机制，并通过比对当前资源的最后修改时间或实体标签
ETag与请求头中的值，判定资源自上次响应后未被修改
在数据包中，明确包含了If-None-Match与If-Modified-Since 。服务器在接收到该请求后，会对目标资源（即根路径/所对应的资源，通常为index.html或其默认文档）的当前元数据执行校验。若当前文件的ETag与If-None-Match匹配，且修改时间不晚于If-Modified-Since，则服务器认定资源未发生变化，不返回响应体，仅返回状态行与响应头，并置状态码为304。这是浏览器与服务器之间标准的缓存协商流程
那么如果要将其变为200的话通常移除If-None-Match与If-Modified-Since头部即可，使其与Etag不匹配，这样返回的内容就跟在浏览器中查看源代码的结果一致
扯了挺多没什么关系的，还是回到拼接路径这一块，既然**#** 只能在浏览器中手动进行拼接，那么先尝试一下雪瞳插件提取出来的api绝对路径接口：
但是这里同样会有路由守卫，没有token的话会重定向到登录页面，代码逻辑类似如下：
js
router.beforeEach((to, from, next) => {
// 检查本地是否存有 token 或 用户登录信息
const token = localStorage.getItem('token');
if (to.path !== '/login' && !token) {
next('/login'); // 没有登录，强制重定向到登录页
} else {
next(); // 放行
}
})既然这样的话那就去掉hash直接在域名上进行拼接，这样就能尝试遍历了：
可以看到返回了一些数据，但是插件提取出了七百多个接口真正返回数据的就这么几个，那么没有返回数据的接口是什么就值得进一步思考：
- 前端路由路径，与后端接口完全无关
列表中大量路径属于Vue Router的前端视图路径，而非后端API端点。典型标志为：路径以/开头但无/api、/auth、/admin、/device、/finance、/order、/bi、/payment、/job、/gen、/act、/mp、/customer、/stock等明确业务域前缀，且路径名称为单一名词或通用视图名称 。此类路径包括但不限于：/login、/404、/401、/lock、/wel/index、/info/index、/index、/code、/message/index、/authredirect、/myiframe、/info、/message、/activti、/activti/detail、/wel、/500、/portal、/main、/home、/tmp等。直接访问域名+此类路径时，由于Nginx无对应的静态文件或代理规则，且本应用部署为hash模式服务器必然返回404。而当/#/+此类路径访问时，这些路径在Vue Router中有所定义，故前端路由守卫会依据登录状态决定是否渲染对应组件或重定向至登录。
- 第二类：后端业务API路径（具备明确业务域前缀），其响应取决于后端路由注册、HTTP方法、认证中间件与路径参数此类路径占据列表的绝大多数，其共同特征是包含
/admin/、/device/、/finance/、/order/、/customer/、/payment/、/bi/、/mp/、/job/、/gen/、/act/、/auth/、/stock/等二级目录。这些路径在Nginx配置中应当被代理至后端应用服务器（如Spring Boot的@RestController映射）。后端应用根据其在@RequestMapping中声明的路径模板进行匹配。若路径模板完全一致且HTTP方法匹配，则执行控制器方法，可能返回JSON数据（若方法内部不强制认证且无异常）；
若路径模板匹配但方法不匹配，则返回405或框架统一映射的404；若路径模板完全不匹配，则返回404。此外，即使路径匹配且方法匹配，若该控制器方法上配置了Spring Security的@PreAuthorize注解或通过过滤器链要求特定角色或认证令牌，而当前请求未携带有效令牌，那么同样没有具体数据：
-
第三类：需要动态路径参数或请求参数才能完整匹配的路径模板列表中大量路径以斜杠结尾或包含占位符，例如:
/customer/tsysmsg/delete/、/admin/tenant/、/device/station/getList 、/order/card-info/export?（含问号表示需参数）、/admin/tcities/list/{{key}}（双花括号为模板占位符）。Spring Boot的路由匹配要求路径中的占位符必须在请求中提供实际值。雪瞳提取的路径丢失了占位符部分，仅提取了基路径。当我们直接访问域名
/admin/user/details/（未提供id）时，后端路由匹配器会尝试将空路径段与{id}匹配，但{id}期望非空段，故匹配失败，返回404 -
第四类：静态资源或非业务路径
列表中出现
/element-ui、/vue-cron、/cdn/avue/、/json/enterprise.json、/json/agent.json等。这些路径在Nginx中通常配置为root目录下的静态文件映射，若文件物理存在，则返回200并附带文件内容；若不存在，则返回404
从这里也能看出雪瞳的局限：
雪瞳无法区分路径来源的上下文。例如，/admin/user/page可能同时出现在router.js中作为页面路径（指向用户管理页面），也可能出现在api.js中作为数据接口。雪瞳仅合并去重后展示，导致用户无法知晓该路径是用于路由跳转还是数据获取
那么下面便是本文的重点，如何扩大攻击面【当然了现在AI很强大一把梭也可以】
在之前的分析中我们直接遍历爆破雪瞳给出的api路径发现/admin/tenant/list接口可以直接进行访问，那么在JS中是否同样有/admin下的路径也能进行未授权访问并且是雪瞳没有找到的？
搜了一下之后自己又尝试了一遍都做了鉴权，那么这里/admin端点似乎就没有什么突破口了，那就可以尝试转api，看看有没有之前没有发现的地方，说不定还有接口文档这类：
搜了一下之后发现只有一个地方，那么好像就没有什么突破口了，但是这时候APIKit发力了，扫出了actuator：
那这还说啥了，曾哥的SpringBoot Scan再扫一波，看看有没有swagger：
看了一下api-docs发现是Pig4cloud脚手架
而这个swagger文档是默认开启的，之前没扫到可能是前缀的问题，加上前缀之后再扫一波就有东西了：
可以看到泄露了更多接口文档地址，这里就拿/admin来进行举例，直接放到APIHunter 里面再扫一波：
有一个新的接口/admin/client/list返回大量信息，这个接口原来在JS里面是搜不到的，可以通过里面的内容进一步利用，后续别的接口利用也同理
回顾整个测试过程，几处关键思路值得沉淀：
架构先行，理解路径的本质------面对 /#/login 这类 hash 路由，第一时间厘清前后端分离的边界，避免在 Burp 中盲目重放前端路由路径，才能将注意力集中到真正可被服务端响应的后端 API 上
工具产出需甄别，分类决定效率 ------雪瞳提取的七百余条路径中，真正具备测试价值的仅为少数具备业务域前缀（如 /admin、/order、/device 等）的后端接口。将前端视图路径、静态资源路径、动态占位符路径与后端 API 路径区分开，能显著减少无效请求，聚焦高价值目标
单一信息源的局限性与工具链互补------JS 文件中未暴露的接口，可能藏在 Swagger、actuator 等运维/开发端点中；而 APIKit 这类流量分析工具恰好能补全静态分析遗漏的"隐藏入口"。从 JS 搜不到，到 APIKit 扫出 actuator，再到 SpringBoot Scan 识别 Swagger 前缀，最后用 APIHunter 展开二次提取，环环相扣地实现了攻击面的"链式放大"
逻辑闭环与纵向延伸------当 /admin 下多数接口存在鉴权时，不必在原地反复试探，转而通过 API 文档寻找更底层的 OAuth 客户端配置、公共数据接口等，往往能打开新的局面
由此引申出的启示是：扩大攻击面不仅是"多扫几个目录"或"多跑几个字典"，更是一种基于架构理解、信息关联与工具协同的思维跃迁 。 在看到一处受限时，主动思考其上游/下游可能存在的配置、文档、监控或调试入口，将"点"上的僵局转化为"面"上的突破，方能有效提升测试深度与发现概率
后续可进一步结合 Swagger 文档中暴露的其他接口，尝试拼接参数、构造合法请求体，验证是否存在越权、敏感信息泄露或逻辑漏洞；同时可关注 actuator 中是否开启 heapdump、env、configprops 等敏感端点，若可访问则可能直接 泄露数据库密码【当然了肯定得分析heapdump】、AK/SK 等高危配置，实现风险等级的再升级