| name | java-api-id-chain-fuzzer |
| description | 基于 ID 串联的 API 逻辑漏洞深度审计工具。支持源码及 jar/class 反编译，精准追踪 Controller 传参点，自动提取并利用泄漏的 ID 进行跨接口参数碰撞，挖掘越权与信息泄露漏洞。内建危险操作（删除/修改等）过滤机制。 |
Java API Parameter Chaining Fuzzer (Java 接口参数串联与实体绑定测试工具)
这是一种结合了 SAST（静态提取）与 DAST（动态发包串联）的高级白盒审计思路。在复杂的业务系统中，接口之间的调用往往存在强关联性。不仅是 ID（如 userid, orderid），任何从一个“查询/列表”接口中返回的参数（如 session_token, report_hash, status），如果被其他接口作为入参要求，都有可能成为水平越权（IDOR）或深度信息泄露的突破口。
本技能通过自动化代码反编译、精准参数追踪、以及基于 JSON 实体的强关联绑定（Entity Binding），实现了这种“参数串联”攻击路径的自动挖掘。它确保从同一个 JSON 对象中提取出的所有字段都被视为一个不可分割的实体（绑定在同一行），从而在后续 Fuzzing 中完美绕过复杂的业务逻辑校验。
🎯 何时调用此 Skill (When to Invoke)
- 用户要求：“帮我找找越权漏洞”、“有没有接口遍历风险”、“审计接口逻辑漏洞”、“测试一下这些参数能不能串起来查到别的信息”。
- 典型指令示例：
使用 java-api-id-chain-fuzzer 审计当前项目，目标发包 URL 是 http://127.0.0.1:8080
- 在获取了项目的源代码、
.jar 或 .class 文件，并希望寻找业务逻辑层的越权与信息泄露漏洞时。
🛠️ 核心工作流 (Execution Workflow)
Phase 1: 资产解析与前置提取 (Asset Parsing & Reconnaissance)
- 反编译支持:
- 检查输入是源码、
.jar 还是包含 .class 的目录（如 WEB-INF/classes）。
- 若无源码，调用
.trae/skills/shared/scripts/batch_decompile_mapper.py 或 auto_decompile.py 将其转换为 Java 源码结构。
- 路由与精准参数提取:
- 调用
java-route-mapper 或相关 AST 提取脚本，扫描所有的 @RestController 和 @Controller。
- 【核心要求】: 必须深入追踪到方法的具体参数定义。例如：
@RequestParam("userId") String userId，或者封装在 @RequestBody UserDTO 中的 userId 字段。
- 记录每个接口的 HTTP 方法（GET/POST 等）和完整的参数结构。
Phase 2: 危险接口过滤与 Agent 语义级安全校验 (Safe Pruning)
为了防止在后续可能的动态发包/逻辑推演中破坏系统数据，必须对提取到的路由进行严格的“破坏性动作”过滤。
【优先级规则】：Agent 的语义确认拥有绝对的最高优先级（具有最终否决权和豁免权），脚本仅作为辅助打标工具。
- 脚本基础过滤 (Warning Flagger): Python 脚本会基于关键字黑名单（
delete, del, remove, update, modify, edit, reset, clear, drop, insert, add, create）进行一轮粗筛，并给这些接口打上 [DANGEROUS] 标签。
- 【关键】Agent 语义确认 (Semantic Safety Check):
- 脚本的正则可能会产生误报（例如
/api/order/getDeliveryStatus 被误打标为 del），也可能会产生漏报（例如一个叫 /api/user/status 的接口其实是用来封禁用户的）。
- Agent 的最终裁决：
- 豁免权：如果脚本标记了某个接口为危险，但 Agent 审阅源码后发现它只是一个纯粹的查询接口（如
getDeliveryStatus），Agent 可以推翻脚本的结论，将其恢复为安全的靶点进行测试。
- 否决权：如果脚本放行了某个接口，但 Agent 审阅源码发现其内部存在
mapper.delete(), repository.save(), updateStatus() 等修改数据库状态的操作，Agent 必须立刻否决，终止对该接口的 Fuzzing 尝试。
Phase 3: ID 提取与关系网构建 (ID Chaining & Graphing)
- 发现泄露源 (Leakage Sources):
- 分析“列表/查询”类接口的返回值（通过分析 Controller 的返回实体类 DTO）。
- 寻找可能返回包含 ID 集合的接口（例如：
GET /api/users/list 可能会返回一批带有 userId 的对象）。
- 寻找利用点 (Exploitation Sinks):
- 在所有安全的读接口中，筛选出那些明确要求传入特定 ID 作为参数的接口。
- 比如：
GET /api/user/detail?userId={id}，或者 POST /api/order/query 且 body 中包含 "userId": "{id}"。
- 构建串联关系图:
- 建立映射关系：
[接口A (Source) 泄漏了 X_ID] ---> [接口B (Sink) 需要 X_ID 作为入参]。
Phase 4: 运行环境配置 (Runtime Configuration Setup)
如果需要执行真实的动态 Fuzzing（DAST 模式），必须确保获取了目标 API 的基准 URL (Base URL)。
- 获取方式：Agent 应首先检查用户的初始指令中是否已经提供了 URL。如果没有提供，Agent 必须通过对话框主动向用户提问（例如：“为了进行动态发包测试，请问目标环境的 Base URL 是多少？”）。
- 由于测试主要针对未授权暴露的接口进行逻辑探测，无需强制要求鉴权 Token 或自身 ID。
Phase 5: 逻辑推演、敏感信息捕获与漏洞报告 (Fuzzing Logic & Reporting)
在明确了串联关系并执行发包后，Agent 必须深度审查返回的 HTTP 响应体：
- 敏感信息自动识别: 无论是在信息收集阶段（Source）还是越权利用阶段（Sink），一旦在 JSON 响应中发现类似
password, phone, mobile, email, cardid, idcard, token 等敏感字段，必须立即捕获！
- 【强制】生成并持久化攻击链路报告: 向用户输出完整的漏洞报告，并必须使用文件写入工具将其追加保存到项目目录下的
fuzzer_vulnerabilities.md 文件中。
- 指出哪个接口是受害者（Sink）。
- 详细列出当时发送的具体参数（Payload）。
- 必须将捕获到的敏感信息（如明文密码、身份证号）清晰地展示在报告中，作为漏洞存在的“铁证”。
⚠️ 运行时约束与安全红线
- 绝对的安全性: 任何对数据库有写、删、改操作的接口，绝对禁止放入 ID 串联的执行或建议列表中。
- 参数溯源: 参数必须精准溯源到用户明确可控的传参点（Query String, Form Data, JSON Body），不能是系统自动注入的上下文 ID（如从 Session/Token 解析出的不可篡改 ID）。
📝 报告输出格式示例
[H-LOGIC-001] 基于 ID 串联的水平越权与高危信息泄露
- 漏洞类型: IDOR / 敏感信息泄露
- 靶点接口 (Sink):
GET /api/v1/user/profile
- 攻击链路 (ID Chain):
- Step 1 (获取靶标 ID): 通过无鉴权接口
GET /api/v1/public/comments 批量收集到了多个 userId (如 10086)。
- Step 2 (越权获取详情): 将收集到的
userId 填入靶点接口进行查询。
- 漏洞利用证明 (Proof of Concept):
- 发包参数:
GET /api/v1/user/profile?userId=10086
- 泄露的敏感数据:
{
"userId": "10086",
"password_hash": "e10adc3949ba59abbe56e057f20f883e",
"phone": "13812345678",
"idcard": "11010519900101XXXX"
}
- 修复建议: 在
UserProfileController.java (Line 88) 中增加鉴权拦截，或者剔除 DTO 中的敏感字段。
