From vuln-reproduce
Deep analysis agent for vulnerability confirmation: traces complete call chains (routing→controllers→services→data), verifies multi-layer defenses for auth bypass (BFLA/IDOR), race conditions, rate limits, info leaks.
npx claudepluginhub Clouditera/AI-Vuln-Reproduce --plugin vuln-reproduce> **Owner**: 分析师 (vuln-analyst) > **适用角色**: vuln-analyst, mock-env-preparer > **v2.0 说明**: 本规则原名 l3-deep-analysis.md，现重命名以适应 v2.0 架构 --- 代码分析必须遵循以下深度分析规则，避免仅看单点代码就下结论。 --- **问题案例**: VUL-002 只看到路由层缺少 `ensureLoggedIn` 中间件，就判定存在授权绕过，但实际上底层函数 `canEditQueue()` 有完整的权限校验。 **规则**: ```yaml 授权类漏洞必须追踪: 1. 路由层 → 中间件检查 2. 控制器层 → 参数处理 3. 服务层 → 业务逻辑权限校验 4. 数据层 → 数据访问控制 只有当整条链路都缺失校验时，才能判定漏洞存在 ``` ``` 请求入口 ↓ 路由...
Reviews completed major project steps against original plans and coding standards. Assesses code quality, architecture, design patterns, security, performance, tests, and documentation; categorizes issues by severity.
Expert C++ code reviewer for memory safety, security, concurrency issues, modern idioms, performance, and best practices in code changes. Delegate for all C++ projects.
Performance specialist for profiling bottlenecks, optimizing slow code/bundle sizes/runtime efficiency, fixing memory leaks, React render optimization, and algorithmic improvements.
Owner: 分析师 (vuln-analyst) 适用角色: vuln-analyst, mock-env-preparer v2.0 说明: 本规则原名 l3-deep-analysis.md，现重命名以适应 v2.0 架构
代码分析必须遵循以下深度分析规则，避免仅看单点代码就下结论。
问题案例: VUL-002 只看到路由层缺少 ensureLoggedIn 中间件，就判定存在授权绕过，但实际上底层函数 canEditQueue() 有完整的权限校验。
规则:
授权类漏洞必须追踪:
1. 路由层 → 中间件检查
2. 控制器层 → 参数处理
3. 服务层 → 业务逻辑权限校验
4. 数据层 → 数据访问控制
只有当整条链路都缺失校验时，才能判定漏洞存在
请求入口
↓
路由中间件（第一层）
↓
控制器权限检查（第二层）
↓
服务层业务校验（第三层）
↓
数据层访问控制（第四层）
任一层有效校验 = 漏洞不成立
必须检查:
- [ ] 路由是否有认证中间件
- [ ] 控制器是否调用权限检查函数
- [ ] 服务层是否验证资源所有权
- [ ] 是否有全局权限拦截器
误判模式:
- 只看路由缺少中间件 → 错误
- 未追踪到服务层校验 → 错误
正确做法:
- 追踪完整调用链
- 找到所有权限检查点
- 验证每个检查点的有效性
示例 - VUL-002 正确分析:
// 路由层 - 看似缺少 ensureLoggedIn
router.put('/queue/:id', controllers.editQueuedContent);
// 但控制器调用了
async function editQueuedContent(req, res) {
const canEdit = await Posts.canEditQueue(req.uid, editData, 'edit');
if (!canEdit) {
return helpers.formatApiResponse(403, res); // ← 这里有校验！
}
}
// 服务层有完整权限检查
Posts.canEditQueue = async function(uid, editData, action) {
// 检查是否管理员
const isAdminOrGlobalMod = await user.isAdminOrGlobalMod(uid);
// 检查是否帖子作者
const selfPost = parseInt(uid, 10) === parseInt(data.uid, 10);
// ...
};
必须检查:
- [ ] 锁机制的作用范围（进程级/分布式）
- [ ] 实际部署场景（单实例/多实例）
- [ ] 数据库层是否有原子操作
- [ ] 是否有事务保护
误判模式:
- 看到内存锁就判定多实例有问题 → 需评估部署场景
- 未考虑数据库层约束 → 错误
正确做法:
- 评估典型部署场景
- 检查数据库层保护
- 考虑实际可利用性
必须检查:
- [ ] 是否有其他层的限速（如 Nginx/WAF）
- [ ] 功能是否默认启用
- [ ] 绕过后的实际影响
- [ ] 是否有其他缓解措施
误判模式:
- 只看代码层缺少限速 → 可能有基础设施层保护
- 未考虑功能是否启用 → 错误
必须检查:
- [ ] 泄露的信息敏感程度
- [ ] 是否需要认证才能访问
- [ ] 信息是否本就是公开的
- [ ] 实际攻击价值
误判模式:
- 公开信息当敏感信息 → 错误
- 未评估实际危害 → 错误
漏洞报告指出的代码位置
↓
确认代码确实存在
↓
理解代码逻辑
从漏洞点向上追踪:
↓
谁调用了这个函数？
↓
调用前有什么检查？
↓
一直追踪到请求入口
从漏洞点向下追踪:
↓
数据流向哪里？
↓
后续有什么校验？
↓
最终影响是什么？
判定清单:
- [ ] 完整调用链已追踪
- [ ] 所有防御层已检查
- [ ] 实际部署场景已考虑
- [ ] 可利用性已评估
只有全部通过才能判定 CONFIRMED
L3 分析报告必须包含：
## 调用链分析
### 请求入口
- 路由: `POST /api/v3/xxx`
- 中间件: [列出所有中间件]
### 控制器层
- 函数: `controllers.xxx`
- 权限检查: [有/无，具体函数]
### 服务层
- 函数: `Service.xxx`
- 业务校验: [有/无，具体逻辑]
### 数据层
- 操作: `db.xxx`
- 访问控制: [有/无]
## 防御层总结
| 层级 | 检查点 | 状态 |
|------|--------|------|
| 路由 | ensureLoggedIn | ❌ 缺失 |
| 控制器 | canEditQueue | ✅ 存在 |
| 服务 | 权限验证 | ✅ 存在 |
| 数据 | - | - |
## 判定
基于完整调用链分析，虽然路由层缺少中间件，但控制器层有完整权限校验，漏洞**不成立**。
| 误判类型 | 表现 | 正确做法 |
|---|---|---|
| 单点分析 | 只看一个代码位置 | 追踪完整调用链 |
| 忽略多层防御 | 只看路由层 | 检查所有防御层 |
| 忽略部署场景 | 假设最坏情况 | 评估典型部署 |
| 过度推断 | 代码可能有问题 | 验证实际行为 |