القائمة
业务逻辑越权与权限边界白盒审计——追用户可控 resource_id / owner_id / batch_ids / amount / state 等字段是否经归属判定、角色判定、状态前提与数量上限，覆盖水平 IDOR / 垂直越权 / 状态机 绕过 / 批量越权 / 金额数量篡改 / 多租户穿透。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | business-logic-auth-review |
| description | 业务逻辑越权与权限边界白盒审计——追用户可控 resource_id / owner_id / batch_ids / amount / state 等字段是否经归属判定、角色判定、状态前提与数量上限，覆盖水平 IDOR / 垂直越权 / 状态机 绕过 / 批量越权 / 金额数量篡改 / 多租户穿透。 |
| when-to-use | 当项目存在登录、session、cookie、controller/service/mapper 链路，且需要补充业务逻辑与权限边界复核时 |
| allowed-tools | bash,read_file,list_files,rg,list_skills |
| user-invocable | true |
| argument-hint | [target_path] [--focus idor|vertical|state-machine|batch|amount] |
| arguments | ["target_path","focus"] |
按 代码 pattern + 项目结构 + 依赖 / 注解三维识别本能力命中场景。
代码 pattern 维度（grep 命中模式）：
@PathVariable Long id / @RequestParam Long resourceId / @RequestParam Long targetUserId / 路径中 /users/{id} / /orders/{orderId} / 批量入口 List<Long> idsif (currentUser.getId() != resource.getOwnerId()) throw new AccessDeniedException() / assert resource.user_id == request.user.idWHERE id = #{id} AND owner_id = #{currentUserId}（安全形态）vs WHERE id = #{id}（候选）if (order.status == PAID) order.status = SHIPPED / enum OrderStatus { CREATED, PAID, SHIPPED, COMPLETED }order.setAmount(req.getAmount()) / quantity = request.json["quantity"]文件位置 / 命名约定维度：
*Controller.java 接收资源 ID 但 Service 无归属判定；*Mapper.xml 含 WHERE id = #{id} 缺 AND owner_idviews.py 用 generic ListView / DetailView 但缺 LoginRequiredMixin / UserPassesTestMixinroutes/*.js 接收 req.params.id 但 controller 直接 Model.findByPk(id)app/Http/Controllers/ 直接 Model::find($id)->delete()，缺 $this->authorize('delete', $model)(parent, args, context) 但未消费 context.user 做角色校验依赖 / 注解维度：
pom.xml 含 spring-security / shiro-spring / sa-token，识别注解使用率requirements.txt 含 django.contrib.auth / django-guardiancomposer.json 含 laravel/framework（Policy / Gate）package.json 含 casbin / accesscontrol / passport@PreAuthorize("@perm.canAccess(#id)") / @RequiresPermissions / @SaCheckPermission / @permission_required 但端点覆盖不全业务命名（getUserOrder / deleteUser / updateProfile）仅作粗筛——sink 语义相同（按 ID 操作他人资源 / 角色断言 / 状态转换）就是审计候选。
本类漏洞的核心是「source = 用户可控的身份 / 资源 / 业务字段」流到「sink = CRUD / 状态转换 / 金额计算 / 批量操作」时缺少必要的服务端校验，攻击者直接构造请求改写 source 即可越权或篡改业务逻辑。常见成因有五类：
UPDATE orders SET ... WHERE id = ? 缺 AND owner_id = ?）。List<Long> ids）循环内未逐条校验，攻击者把他人 ID 混入数组。更深一层的根因是信任边界设置错误——前端 / Cookie / 请求参数被信任为身份 / 业务事实来源，而服务端 session / SecurityContext / 数据库才是真正的 source-of-truth。
代码层 source 集合（按来源分类）：
@PathVariable Long id / @RequestParam Long resourceId / req.params.id / request.GET['id'] / $_GET['id']@RequestParam Long targetUserId / req.body.userId / request.json['user_id']List<Long> ids / []int64 / req.body.ids: number[] / request.POST.getlist('ids')amount / quantity / discount / state / status / role / tenant_idCookie["userId"] / req.headers['x-user-id'] / request param "currentUser"——任何来自客户端的"身份"声明都属潜在 source代码层 sink 集合（按操作类型分类）：
Mapper.updateById / Mapper.deleteById / repo.save(entity) / Model.objects.filter(id=x).delete() / DB::table('x')->where('id',$id)->update(...)order.setStatus(SHIPPED) / workflow.transition(state) / entity.status = 'approved'total = price * quantity / order.amount = req.amount / cart.discount = req.discountfor (Long id : ids) mapper.deleteById(id) / ids.forEach(id => Model.delete(id))SELECT * FROM orders WHERE id = ? 不带 tenant_id / owner_id 条件数据流追踪规则（本能力专属——多 source 多 sink 交叉）：
本类漏洞 source 与 sink 不是 1:1 配对，必须交叉验证以下四种约束至少其一在数据流中生效：
current_user.id == resource.owner_id 或 SQL 内 AND owner_id = #{currentUserId} 出现@PreAuthorize("hasRole('ADMIN')") / if (user.role != 'admin') / subject.checkRole('admin') 等显式角色断言if (order.status == PAID) 才允许转 SHIPPED）if (quantity > limit) reject / 金额从服务端 source-of-truth 重新计算后比对跨函数 / 跨文件追踪边界：
static-unknown| 类型 | 静态识别特征 | 白盒识别难点 |
|---|---|---|
| 水平越权 IDOR | 同角色 / 同租户用户互读 / 互改资源；Mapper SQL 缺 AND owner_id = ? | AOP 拦截器统一加 owner 条件（看不到）/ ORM scope 自动加（typeorm scope / Django manager for_user） |
| 垂直越权 | 普通用户访问管理端接口；admin 端点缺角色断言或仅靠 session != null | admin / 普通端共用 Service 方法，单看 Service 看不出端点角色差异 |
| 状态机绕过 | 状态字段直接被 setter 改写 / 转换前无前置状态判定 | 状态枚举多分支时逻辑分散；用 Spring StateMachine 时跨配置文件 |
| 批量越权 | List<ID> 入参，循环体内未逐条校验归属 | 单项端点安全 → 误以为批量也安全；批量接口可能复用单项校验但漏点不同 |
| 金额 / 数量篡改 | setAmount(req.getAmount()) / 折扣率 / 库存从请求取值后直接计算 | 前端"展示价"传后端被信任；负数 / 整数溢出 / 浮点精度边界 |
| 数据归属字段被信任前端 | 实体绑定（@RequestBody / BindJSON）把 ownerId / tenantId / role 字段直接覆盖 | 自动绑定无 DTO 白名单，看 Controller 表面正常 |
| 操作者 vs 操作对象混淆 | 同一字段名（userId）在不同上下文（操作者 / 被操作对象）含义不同 | Controller 用 userId 当操作者，Service 把它当被操作对象 |
| 跨租户数据穿透 | 多租户系统查询缺 tenant_id 约束 / tenant_id 从 request 取值 | tenant 上下文从 SecurityContext 拿（看不到 SQL 显式拼接） |
按项目结构定位 source / sink 候选位置——Controller 找 source / Service 找校验层 / Mapper / Repository 找 sink。
下列框架 / 项目类型仅作类似项目示例，不限于此；以目标实际栈为准。
*Controller.java：参数中接收资源 ID（@PathVariable / @RequestParam）；注解层 @PreAuthorize / @Secured 是否齐全；@RequestBody 接收实体时看 DTO 是否含 ownerId / role 等敏感字段*Service.java：是否有 findByXxxAndCurrentUser 模式（安全）vs findByXxx（候选）；状态转换方法是否检查前置状态*Mapper.xml / @Mapper：WHERE id = #{id} 缺 AND owner_id = #{currentUserId}；批量 <foreach> 内是否含归属约束pom.xml：识别 Spring Security / Shiro / Sa-Token 引入，确认是否全局生效views.py：generic CBV（ListView / DetailView）缺 LoginRequiredMixin / UserPassesTestMixin / PermissionRequiredMixin；get_queryset 是否按 request.user 过滤models.py Manager：自定义 for_user(user) Manager 方法（安全）vs 直接 objects.all()viewsets.ModelViewSet 的 permission_classes / get_queryset 是否覆盖归属settings.py：AUTHENTICATION_BACKENDS / DEFAULT_PERMISSION_CLASSES 是否设置routes/*.js / controllers/*.js：req.params.id 直接 Model.findByPk(id) 缺归属过滤requireAuth / requireRole 中间件挂载是否覆盖目标路由where: {ownerId: req.user.id}package.json：识别 passport / casbin / accesscontrol 引入app/Http/Controllers/：Model::find($id)->delete() 缺 $this->authorize('delete', $model)app/Policies/：Policy 类实现 + Controller / route 是否真调用 authorize / canauth / can:xxx 中间件挂载router.go / main.go：找 handler 函数，追到 service / repositoryc.Param("id") / c.Query("user_id") 直接传到 DAO 缺 currentUser 拼接(parent, args, context) => Model.findById(args.id) 是否消费 context.user 做角色 / 归属校验@auth(requires: ADMIN) / @hasPermission 注解是否覆盖sast-scan 输出的 business-logic-auth-review 候选清单加速定位（如有）主流框架的"安全形态 vs 危险形态"对照（精选）：
| 框架 | 安全形态（含校验） | 危险形态（缺校验） |
|---|---|---|
| Spring Security | @PreAuthorize("@perm.canAccess(#id, principal)") 全覆盖 | 端点缺注解 / permitAll() 过宽 / SpEL 绕过 |
| Spring + MyBatis | WHERE id = #{id} AND owner_id = #{currentUserId} | 仅 WHERE id = #{id}；批量 <foreach> 内无 owner |
| Shiro | Subject.checkPermission("order:edit:" + id) / @RequiresPermissions | 仅 Subject.isAuthenticated()；anon 过宽 |
| Sa-Token | StpUtil.checkPermission / @SaCheckPermission | 仅 StpUtil.isLogin() |
| Django auth | UserPassesTestMixin + test_func；get_queryset filter by request.user | 普通 ListView 无 Mixin；queryset 全表 |
| Laravel Policy | $this->authorize('update', $model) / Gate Gate::allows | 直接 Model::find($id)->update(...) |
| Express + Casbin | enforcer.enforce(sub, obj, act) | 仅 JWT 有效性检查 |
| NestJS | @UseGuards(RolesGuard) + custom OwnerGuard | 仅 @UseGuards(AuthGuard) |
| GraphQL（graphql-shield） | permissions.compose({Query: {getUser: isOwner}}) | resolver 内裸 Model.findById(args.id) |
业务字段被信任的危险点（任何框架适用）：实体自动绑定（mass assignment）/ Cookie / Header 注入身份 / 金额 / 数量 / 折扣率从前端取值 / 状态字段直接 setter。
完整框架对照（Shiro / Sa-Token / DRF / NestJS / Flask / FastAPI 等）、ORM scope / Manager / hook 等"看不见的校验"识别位置、mass assignment 修复模板见 references/framework-patterns.md。
加载本 skill 时按这些问题按 sink 语义思考（不按业务命名）：
本能力只到
static-confirmed（静态可达 + 中间无校验）——动态确认走黑盒越权请求验证（见 §9）。本节方法论描述白盒追踪，不规定 plan / step 编排。
project-framework-analysis 输出（如有）：项目所有 Controller + 角色清单 + 数据模型归属字段 + 多租户标识按框架 grep 路由声明（Spring @*Mapping / Flask @app.route / Express router.get|post|... / Laravel Route::* 等）输出 (端点, HTTP方法, source 字段, 可见角色断言) 四元组；建 admin / operator / owner / guest 四态 × 端点矩阵，每格标预期可访问性。
对每个端点四层逐一查校验：
for_user 模式@PreAuthorize / @RequiresPermissions / Policy authorize 调用）工具加速：调用 dataflow-analysis MCP 工具做跨函数数据流追踪；调用 sast-scan 拿粗筛候选。
详细的 IDOR 逐步验证脚本（含 8 步分类协议与案例库索引）见 references/idor-protocol.md。
找所有状态字段（status / state / phase）和枚举定义；列出所有状态转换路径；每条转换路径检查前置状态判定 / 触发者角色 / 业务前提。
grep List<Long> / []int64 / ids: / batch / bulk / multi 命名的端点；循环体内是否对每个 ID 逐条做归属校验；对照同资源的单项端点——单项有归属检查而批量没有 → 高危信号。
grep setAmount / setPrice / setQuantity / setDiscount 等业务字段 setter；跟踪赋值来源是 request 还是 DB / 配置 source-of-truth；最终计算 / 持久化位置应按服务端 source-of-truth 重算。
grep Cookie.*getValue / request.getHeader("X-User-Id") / req.headers['x-user-id'] 等"客户端注入身份"通道；currentUser 上下文应唯一来自服务端 session / JWT 签名验证后的 claims；任何旁路 → 高危。
以下是已知的检查角度，作为基线起点而非必检硬清单。结合目标代码动态调整，按三态标注（
[x]/[-]/[+]）处置。
List<ID> / batch / bulk / multi）独立扫描static-unknown 而非默认 not_vulnerable闭环判定 / 取证完整性 / 破坏性动作以 common/closure-verification.md 为准，下面只列本漏洞特有的判定上限与产物契约。
为什么这里是「必须」：本节属交付契约——产物结构关系到下游
result-with-file机器消费与计数闸门；判定上限错位会让"白盒已审"被误读为"动态确认"，导致整条链路失真。
本能力作为白盒原子能力，判定上限为 static-confirmed（静态可达性已证），不等于动态 confirmed。
static-confirmed（落 status=needs_review）：
static-unknown（落 status=needs_review + 标注 unknown）：
@Aspect / Interceptor / Middleware 改写 request 上下文（看不到）not_vulnerable（落 status=not_vulnerable）：
升级路径（白盒不能独立给 confirmed）：
static-confirmed 升为 confirmed禁止白盒独立判 confirmed——无可观测效果证据，仅静态可达不构成动态利用。
每确认一条候选立即 append 一行到 shared/coverage-ledger/findings/business-logic-auth-review.jsonl，不等汇总阶段回头整理：
{
"id": "bla-001",
"title": "订单详情接口缺少归属校验",
"severity": "high",
"cwe": "CWE-639",
"source": "@PathVariable Long orderId",
"sink": "OrderMapper.selectById",
"entry_point": "GET /api/orders/{orderId}",
"victim_role": "owner",
"actor_role": "owner",
"vuln_type": "idor-horizontal",
"status": "needs_review",
"confidence": "static-confirmed",
"file_location": "OrderController.java:42",
"source_report": "business-logic-auth-review",
"description": "..."
}
字段约束：
id 带 bla- 前缀全局唯一status ∈ confirmed | needs_review | not_vulnerable | false_positive | superseded（白盒默认 needs_review）confidence ∈ static-confirmed | static-unknown | not-applicablevuln_type ∈ idor-horizontal | idor-vertical | state-machine-bypass | batch-auth-gap | amount-tampering | mass-assignment | tenant-isolation(entry_point, actor_role, victim_role, vuln_type) 四元组任一不同即各自独立成行——禁止合并折叠actor_role / victim_role 取 admin | operator | owner | guest | anonymousfile_location 填 file:line，不留空、不写区间why：白盒"权限边界完整"结论是覆盖完整性产物声明，缺失反向验证会让下游误信"该子系统该维度安全"。
写"权限边界完整"或"未发现越权"前，产物必须包含：
static-unknown 单元格的具体原因（AOP / 闭源 / RPC / 动态策略）清单不完整 → 结论降级为 partial-coverage。
参考案例库（执行验证协议前可读）：
反例 1：AOP 拦截器统一做归属校验
@Aspect / Around advice 在 sink 调用前注入 owner 判定，Controller / Service 单看都没校验@Aspect class AuthAspect { @Around("@annotation(AuthCheck)") ... } 配合 @AuthCheck 注解@Aspect 类 / Spring AOP 配置 / 自定义注解；端点上有特定注解（如 @AuthCheck / @OwnerOnly）static-unknown 而非直接判 not_vulnerable反例 2：中间件层做了角色判定，Service 单看是裸的
Model.findByPk 看似裸调app.use('/admin', requireRole('admin'), adminRouter)反例 3：ORM 自动加 tenant_id / owner_id 过滤
for_user / Sequelize hook beforeFind 自动注入 WHERE 条件@Scope(["active", "current-tenant"]) 自动加 tenant_id；Django 自定义 Manager 重写 get_queryset反例 4：批量接口循环里漏校验
selectByIds vs selectByIdAndOwner），SQL WHERE 条件差异反例 5：状态机用枚举但缺前置状态判定
setStatus(OrderStatus s) 无前置状态判定可被跨步调用setStatus / transition 调用，看是否有 if (status == X) 前置判反例 6：数据归属字段从 Cookie 取值
Cookie["userId"]），用户可篡改 Cookie 注入任意身份Cookie.*getValue.*[uU]ser / request.getCookie + 身份字段名反例 7：admin 端复用普通端代码且共用 Service 无角色分支
反例 8：闭源依赖里的权限校验默默被忽略
external-auth-lib.checkOwner(user, resource) 看似有校验，但闭源库内部可能仅 log 不抛异常unknown 标注）static-unknown 推 dependency-decompile 做反编译；不能默认为 not_vulnerable更多场景化反例见 references/ 案例库（client-derived operator / 跨端点独立性 / mass assignment / tenant isolation 各有专题）。
白盒底线：不假装看到看不到的代码。本能力的可观测能力到代码层 pattern + 跨函数追踪为止。
下面这些情形数据流分析无法继续追踪，必须标 static-unknown，不允许默认为 not_vulnerable：
@Aspect / Spring Interceptor / Django middleware 改写 request 上下文——独立读拦截器实现确认覆盖端点，不能仅看 Controller 判 not_vulnerable@Scope / Django Manager for_user / Sequelize beforeFind / GORM scope）——读实现确认所有查询路径都触发，任一旁路未触发标 static-unknownMethod.invoke / Python getattr / JS obj[methodName]()）——记录反射点行号底线：本能力写"权限边界完整"前，所有 static-unknown 单元格必须显式列出原因。否则结论降级 partial-coverage。
协作工具：
sast-scan：粗筛"按 ID 操作他人资源"端点候选dataflow-analysis：跨函数追 source-to-sink 可达性session-security：身份上下文完整性专项dependency-decompile：闭源依赖反编译追踪所有按 ID 操作他人资源的 Mapper SQL 加归属约束：
<!-- 危险 -->
<select id="selectById">SELECT * FROM orders WHERE id = #{id}</select>
<!-- 安全 -->
<select id="selectByIdAndOwner">
SELECT * FROM orders WHERE id = #{id} AND owner_id = #{currentUserId}
</select>
权限判定在 Service 入口统一做：取出资源后比对 resource.ownerId == currentUser.id || currentUser.isAdmin()，否则抛 AccessDeniedException。不依赖前端隐藏 / 不依赖路由路径。
批量接口循环内逐条校验：取出资源集合后 forEach 内逐条比对 ownerId，任一不匹配抛异常。批量大小加上限。
状态转换显式检查前置状态：shipOrder / completeOrder 等业务方法内先校验 order.status == PAID 才允许转 SHIPPED，状态字段不允许直接 setter 暴露。
金额 / 数量从服务端 source-of-truth 重新计算：订单总价 = SELECT price FROM goods WHERE id = ? × quantity；折扣率从配置 / 优惠券表查；数量加范围检查；不信前端传值。
实体绑定时显式排除敏感字段：用 DTO 白名单 / @JsonIgnore / fillable 配置，禁止 @RequestBody UserEntity 直接覆盖 role / ownerId / tenantId。详细模板见 references/framework-patterns.md 业务字段被信任的危险点段。
@PreAuthorize）+ Service 业务校验层双层白盒建模——一次深度建模产出五张共享模型：项目架构（技术栈/分层/框架自有封装/闭源依赖位置）、 入口点（路由/中间件信任边界）、认证与权限（会话/角色/多租户/归属字段）、业务（实体/流程状态机/ 业务不变量/高价值资产）、全局威胁（攻击面×漏洞类别的适用性映射，供下游逐一全测）。本能力不做漏洞判定，为后续 漏洞维度分析建立共享底图。
OS 命令注入综合检测——覆盖直接命令拼接 / shell 元字符 / 参数注入 / 间接 RCE，按回显 / 时间 / 带外通道分诊。 流量中参数值含主机名 / URL / 文件名 / 命令片段、响应里出现 shell 错误关键字（`/bin/sh` / `cmd.exe` / `command not found`）、注入 `sleep N` 耗时增加、上传后异步处理链路时使用。
文件上传多策略综合检测——覆盖扩展名 / MIME / 魔术数 / 解析漏洞 / 上传链组合（LFI / Zip Slip / SVG XSS / SVG XXE）。 流量含 multipart/form-data 上传、响应回显落盘路径、上传后文件可被 GET 解析、上传字段含 filename / path 可控时使用。
IDOR 水平越权检测 — 通过替换资源标识符（ID/UUID/路径）访问他人资源的风险；适用于用户资料、订单、文档、租户隔离场景。
检测路径穿越和本地文件包含（LFI）风险；当目标存在文件读取/下载/预览功能且含路径参数时触发；适用于文件下载、日志查看、模板加载等场景。
黑盒建模 — 迭代式攻击面建模，按站点级 / 页面级 / 功能级三粒度推进；进入新页面即触发一次页面级建模、切换新身份各刷新一次，产出端点账本与页面语义模型，为后续漏洞维度的适用性判断提供依据。