Strix BFLA 深度测试指南：功能级授权绕过（Broken Function Level Authorization）的探测与验证

导读

broken-function-level-authorization 是 Strix 内置在 strix/skills/vulnerabilities/ 目录下的漏洞类技能，聚焦于动作级（action-level）授权失效：普通用户可以调用本不应有权限的函数，例如管理端点、GraphQL mutation、后台任务或 gRPC 方法。读完本指南，你将掌握在 Strix 扫描与人工渗透中系统化定位 BFLA 的方法——从角色矩阵构建、跨传输层一致性检查、关键绕过技巧，到具备审计价值的 PoC 验证与误报排除。

BFLA 的本质：动作没有绑定到服务边界

BFLA 是动作级授权失效：调用者调用其无权使用的函数（端点、mutation、管理工具）。当各传输层、网关、角色之间的执行存在差异，或服务信任客户端提示信息时，它就会出现。必须在执行动作的服务处绑定 subject × action。

与 IDOR（对象级授权，见同目录的 idor.md）不同，BFLA 关心的是"谁被允许执行哪个函数"，而非"谁能访问哪个对象"。在 Strix 的知识分类中，这两者被分别建模：broken_function_level_authorization 的描述是 "BFLA testing for action-level authorization failures across endpoints, admin functions, and API operations"，其 frontmatter（name + description）即被 strix/skills/init.py 中的解析器读取，供技能注册与按需加载使用。

攻击面与高价值动作

攻击面清单

• 垂直授权（Vertical authz）：本应只有特权/管理员/员工可执行的动作，被普通用户触达；
• 功能开关（Feature gates）：开关只在边缘/UI 层强制，而非核心服务层；
• 传输层漂移（Transport drift）：REST、GraphQL、gRPC、WebSocket 之间的授权检查不一致；
• 网关信任（Gateway trust）：后端信任由代理/边缘注入的 X-User-Id / X-Role 头；
• 后台任务：worker/job 执行动作时未重新校验授权。

高价值动作参考

并非所有功能都值得优先测试。以下动作一旦出现 BFLA 缺陷，影响通常直达业务与合规：

类别	示例动作
账户与权限	角色/权限变更、模拟/提权（impersonation/sudo）、邀请/接受加入组织
资金与计费	审批/作废/退款/发放积分、价格/套餐覆盖
数据与状态	导出/报表生成、数据删除、账户停用/重新激活
平台配置	功能开关切换、配额/授权额度调整、许可证/席位变更
安全设置	2FA 重置、邮箱/电话验证绕过

值得说明的是，这组"高价值动作"会在两个方向上被 Strix 复用：一是让授权测试 Agent 聚焦高收益目标，二是供 Agent 在汇报覆盖范围时作为语义参考——strix/report/coverage.py 中将 "function level authorization"、"authorization"、"access control"、"privilege escalation" 映射为该技能对应的措辞，Agent 扫描后必须记录"是否真的检查了授权类"，否则会被机器观察到 coverage gap（unrecorded_risk_class），写入 coverage.json，报告语义即"未检查 ≠ 未发现问题"。

侦察：从枚举到信号识别

表面枚举

• 管理员/员工控制台与 API、支持工具、经网关暴露的内部端点；
• UI 中隐藏或被功能开关遮蔽的按钮与禁用路径，映射到仍然存活的后端端点；
• GraphQL schema 中的 mutation 与仅管理端可见的字段/类型；gRPC 通过 reflection 暴露的服务描述符；
• 移动端应用包或网络日志中额外暴露的端点与角色。

高风险信号

• UI 返回 401/403，但直接调用 API 返回 200；不同传输层返回的状态码不一致；
• 直接调用被拒绝，但经由后台任务执行成功；
• 只修改头部（role/org）而不更换 token，访问权限就发生变化。

核心漏洞模式

动词漂移与别名（Verb Drift and Aliases）

• 备用方法：用 GET 触发状态变更；POST 与 PUT/PATCH 行为差异；X-HTTP-Method-Override 或 _method 参数覆写；
• 同一动作存在执行相同功能的备用端点，但授权检查更弱（legacy 与 v2、移动端与 Web 端各自成对）。

边缘与核心不匹配（Edge vs Core Mismatch）

• 边缘网关拦截某动作，但核心服务的 RPC 可直接接受；可通过暴露的 API 路由或 SSRF 直达内部服务；
• 网关注入的身份头覆盖 token 声明；通过提供冲突头来测试优先级。

功能开关绕过（Feature Flag Bypass）

• 只在客户端检查的功能开关，直接调用后端端点即可绕过；
• 仅管理员可见、但真实暴露的 mutation，通过 GraphQL 或 gRPC 工具直接调用。

批处理任务路径（Batch Job Paths）

• 导出/导入任务允许创建，但 finalize/approve 缺少授权——可替他人终结任务；
• 重放 webhook/后台任务端点，这些端点执行特权动作却不校验调用者。

Content-Type 路径

• JSON、form、multipart 走不同的中间件链；通过最宽松的解析器发送同一动作即可绕过。

高级技术与跨协议绕过

GraphQL

不要假设顶层鉴权能覆盖嵌套 mutation 或管理字段，必须在每个 resolver 上做检查。别名/批处理是走私特权字段的惯用手段，persisted queries 有时还能绕过鉴权转换：

mutation Promote($id:ID!){
  a: updateUser(id:$id, role: ADMIN){ id role }
}

gRPC

• 通过 interceptor 做方法级鉴权时，必须校验 audience/roles；使用低角色 token 直连 gRPC 探测；
• Reflection 会列出全部服务与方法，可据此调用网关隐藏的管理方法。

WebSocket

• 仅在握手时鉴权是不够的：必须在每条消息上做授权检查（例如 admin:impersonate 事件）；
• 加入标准频道后尝试发射特权动作。

多租户（Multi-Tenant）

• 租户管理员动作只靠 header/subdomain 强制：使用同一 token 切换 selector（X-Tenant-ID、org slug 等），尝试跨租户执行管理动作。

微服务

• 内部 RPC 信任上游的授权检查；通过暴露端点或 SSRF 触达它们，验证每个服务是否重新执行授权。

绕过技巧集

技巧	做法
Header 信任	提供 X-User-Id / X-Role / X-Organization；移除或制造与 token 声明矛盾的取值，观察哪一方"获胜"
路由遮蔽	legacy/备用路由（如 /admin/v1 vs /v2/admin）绕过了新的中间件链
幂等与重试	重试/重放 finalize/approve 端点——每次调用若未检查 actor，状态就会被反复应用
缓存键混淆	边缘缓存的授权决策被跨用户复用；用 Vary 头和会话切换验证

系统性测试方法论

Strix 中授权测试不应是零散的"试几个管理 URL"，而应按下述五步执行：

1. 构建 Actor × Action 矩阵——未认证、普通用户、高级用户、员工/管理员各为一档，逐角色枚举可执行的动作；
2. 为每个角色获取 token/会话；
3. 在所有传输层与编码上执行每个动作——JSON、form、multipart，包含方法覆写；
4. 变化 header 与 selector——org/tenant/project 维度；分别测试经网关与直连服务；
5. 纳入后台流程——任务创建/finalize、webhooks、队列；确认每次都重新校验。

这套矩阵思路与 Strix 的 Agent 编排天然契合：在 strix/skills/coordination/root_agent.md 中规定，协调根 Agent 不直接触碰目标，而是按漏洞类别派生专职子 Agent（在 strix/agents/factory.py 通过 create_agent(skills=[...]) 传递技能），例如把"授权验证"拆给携带 broken_function_level_authorization 技能的子 Agent，使其专注执行上述矩阵步骤。

验证：让 PoC 经得起审计

一份可上报的 BFLA 发现必须同时满足四条：

1. 用同一输入证明低权限主体成功调用了受限动作，且同条件下：正确角色成功、另一个更低角色失败（形成三角对照）；
2. 在至少两个传输层或编码上给出证据，证明执行（enforcement）不一致；
3. 演示移除/篡改客户端门控（按钮/开关）不影响后端成功返回；
4. 附持久状态变更证据：before/after 快照、审计日志、权威数据源。

对应到 Strix 的 Agent 技能加载与覆盖上报机制，这些证据最终会与 Agent 在运行时记录的工具调用、覆盖条目对齐，成为 coverage.json 中 agent_reported 的来源（详见 strix/report/coverage.py）。换言之，"验证充分"本身就是 Strix 报告语义的一部分。

误报排除（False Positives）

• 被标记为 admin 但公开文档化的只读端点；
• 明确对所有角色开放 preview/beta 的功能开关（需有清晰的策略声明）；
• 模拟/演示环境中被 stub 化、无副作用的管理端点。

影响评估

BFLA 一旦确认，风险等级通常偏高：

• 提权至管理员/员工动作；
• 资金/状态影响：未经授权的退款、积分、审批；
• 租户级配置变更、身份模拟或数据删除；
• 因绕过审批工作流导致的合规与审计违规。

Pro Tips

1. 从角色矩阵出发：对每个动作使用普通 vs admin token，横跨 REST/GraphQL/gRPC 逐一测试；
2. 对比中间件栈：不同路由的授权链强弱不同，弱链往往存在于 legacy 路由或备选编码上；
3. 审查网关的身份头注入：绝不信任客户端提供的身份；
4. 把任务/webhook 当作一等公民：finalize/approve 必须重新校验 actor；
5. 优先最小化 PoC：一条请求用普通 token 翻转特权字段或调用 admin 方法即可。

技能在 Strix 中的工作方式

本文所述能力并不是一份孤立的静态文档。在 Strix 中，技能文件以 YAML frontmatter 声明元数据，由 strix/skills/init.py 的 load_skills() 在运行时读取并剥离 frontmatter；两个注入通道（详见 docs/advanced/skills.mdx）：

• 预载（preload）：Agent 创建时通过 create_agent(skills=["broken_function_level_authorization", ...]) 绑定，技能正文会被直接注入系统提示词中的 <specialized_knowledge> 区（渲染逻辑见 strix/agents/prompt.py）；
• 按需加载（load_skill）：未预载时，Agent 在执行具体动作前调用 load_skill(skills=[...]) 把技能拉进会话（工具实现见 strix/tools/load_skill/tool.py），每 Agent 最多 5 个技能。

此外，broken_function_level_authorization 还被其他技能交叉引用，例如 strix/skills/technologies/llm_applications.md 中针对 OWASP LLM03:2026（Excessive Agency）的测试策略，就建议与该技能协同使用。

小结

授权必须在每次请求与每条消息上，于服务边界处把 actor 绑定到具体 action。UI 门控、网关或之前的任何步骤，都不能替代函数级检查——这就是 BFLA 测试的核心判断标准，也是 Strix 将本技能收编进 vulnerabilities 分类（连同 idor.md、business_logic、race_conditions 等，见 docs/advanced/skills.mdx）的原因：只有把"每个动作必须自证授权"变成 Agent 的系统性行为，授权测试才能从碰运气升级为可审计的工程实践。