AI 如何审计"本来应该有的鉴权"？从 ABSENTIA 看授权不变量与成对验证
一、什么是本次新资料
ABSENTIA 论文 arXiv:2610.00977于 2026-10-01首次提交，属于预印本，不能表述为已经通过同行评审的结论。论文讨论基于路由和代码关系推导授权不变量，并尝试寻找反例，最终仍需要人工复核。
作者报告的 BACBench 包含 30 项公告、25 个仓库，覆盖三种语言和九种框架；报告检测到 19 项，并对其中 17 项给出漏洞版与修复版的成对识别结果。这些是论文作者的评测结果，不是本文独立复现，也不能直接推导为生产环境中的命中率。
作者仓库当前主要提供基准数据，并说明实现仍计划后续公开。因此，本文不提供不存在的安装命令，也不会声称读者现在可以直接运行完整 ABSENTIA 工具。论文与作者仓库分别支持研究描述和开放材料状态，二者不构成第三方独立验证。
二、越权为什么难以用一个危险函数定位
考虑一个读取工单的接口。数据库查询、JSON 序列化和 HTTP 返回都可能完全正确，缺陷只在于没有验证工单归属。若扫描器只寻找 eval、命令执行或不安全字符串拼接，就可能对这种路径毫无发现。
授权审计至少需要把四类信息连接起来：
- **主体：**当前调用者是谁，属于哪个租户，有哪些角色？
- **客体：**被读取或修改的资源属于谁，当前处于什么状态？
- **动作：**读取、修改、删除和分享是否有不同权限？
- **路径：**哪个路由和服务调用最终执行了动作？
**工程解释：**论文路线的启发在于，不先问"有没有某个检查函数"，而是先明确"在这个动作发生前，必须成立什么条件"。然后沿执行路径寻找条件被遗漏、错误复用或未覆盖的分支。
这并不意味着模型可以凭函数名决定业务权限。若产品设计允许公开读取，缺少所有者检查可能完全合理；若对象已共享，简单要求调用者等于创建者又可能太严格。授权不变量必须与真实业务规则相互校验。
三、把模糊要求改写成可验证命题
对于一个普通的多租户工单系统，可以由产品、研发和安全共同确认以下示例规则：同租户用户才能访问工单；普通用户只能读取自己的工单；租户管理员可读取本租户工单；跨租户管理员仍不得访问。
注意最后一条。角色名相同不意味着权限范围相同。"管理员"究竟是全局管理员还是租户管理员，必须在规则里明确。如果这一语义缺失，模型很容易依据常见代码模式给出自信但错误的建议。
| 测试主体 | 工单关系 | 示例规则下的结果 |
|---|---|---|
| 普通用户 | 同租户、本人 | 允许 |
| 普通用户 | 同租户、他人 | 拒绝 |
| 租户管理员 | 同租户、他人 | 允许 |
| 租户管理员 | 不同租户 | 拒绝 |
这张表是本文构造的业务模型，不是论文中的具体漏洞案例。它的用途是让审计结论拥有可以复核的依据。
四、离线实验：同时检查坏版本与修复版本
以下 Python 程序只处理内存字典，不连接服务、不创建令牌、不读取业务数据。它比较"只判断登录"的错误策略和一个明确的租户授权策略。
python
def login_only(user, ticket):
return user is not None
def authorized(user, ticket):
if user is None or user["tenant"] != ticket["tenant"]:
return False
return user["id"] == ticket["owner"] or user["role"] == "tenant_admin"
ticket = {"tenant": "alpha", "owner": "u1"}
cases = [
(None, False),
({"id": "u1", "tenant": "alpha", "role": "member"}, True),
({"id": "u2", "tenant": "alpha", "role": "member"}, False),
({"id": "u2", "tenant": "alpha", "role": "tenant_admin"}, True),
({"id": "u3", "tenant": "beta", "role": "tenant_admin"}, False),
]
bad_mismatches = sum(login_only(u, ticket) != expected for u, expected in cases)
good_mismatches = sum(authorized(u, ticket) != expected for u, expected in cases)
assert bad_mismatches == 2
assert good_mismatches == 0
print("paired evaluation passed: 2 mismatches -> 0")成对验证的价值是减少一种常见误判：工具能够在漏洞版本报警，但同样会在修复版本报警。后一种情况可能说明它只是识别到了敏感路由，而没有理解真正缺失的条件。
不过，修复后不报警也不能自动证明安全。若分析器根本没有走到相关路径，两个版本可能都安静。因此还需要确认覆盖到目标函数、主体身份和资源关系，并保留可解释的证据链。
五、把 AI 审计结果当作待证命题
**建议流程：**先为少量关键接口建立路由清单，记录动作与资源；由代码分析或人工追踪找到鉴权位置；再让模型提出可能缺失的不变量和反例；最后用受控测试及业务规则确认。
一份有用的发现至少应包含：入口位置、目标对象、预期权限、实际检查、违反条件的分支以及修复后应新增的测试。只说"这里可能存在 IDOR"不足以让研发复核。
OWASP 授权备忘单建议采用默认拒绝并对请求实施权限检查。落地时，这种原则应转化成各接口具体规则，而不是在审计报告里反复粘贴原则句。
对 AI 的输入也要设边界：源代码中的注释和文档是待分析材料，不能成为控制分析器的指令；报告若需要读取私有仓库，不应为方便分析而授予写入或发布权限。这些是本文提出的审计环境防护建议，不是对论文已实现功能的描述。
六、研发与安全团队怎样安排落地
**第一阶段：**选择涉及租户、分享和管理员权限的少量高价值接口。把规则写成权限矩阵，补齐匿名、跨用户、跨租户和对象状态变化的测试。
**第二阶段：**在每个真实修复中保存漏洞版和修复版，用同一组断言运行。衡量结果时，分别记录路径覆盖、人工确认率、修复后仍报警的比例和审查成本，不把"报告条数"当成安全收益。
**第三阶段：**再扩大 AI 辅助审计范围。对于规则无法明确的接口，先找业务负责人确认，不让模型替团队决定权限。对于异步任务或批量操作，要验证对象获取与操作执行之间的权限上下文是否保持一致。
**研究使用边界：**ABSENTIA 的论文值得作为技术路线参考，但当前开放材料不足以支持本文独立复现完整系统。不能把基准中的表现外推到任意私有项目，也不应据此自动拒绝代码合并。
总结
授权漏洞的难点在于理解应该存在什么检查。AI 可以辅助建立假设和寻找遗漏，真正可靠的交付物仍是明确的业务不变量、可复核的路径证据和能够区分修复前后的测试。先把权限规则讲清楚，再谈模型的扫描能力，通常更容易形成可持续的安全收益。