AI 辅助 AuthZ 审计：解读 Ory Kratos 中的权限边界

AI 不擅长发现漏洞，但非常擅长制造怀疑。

在安全领域，AI 能做的成本最低的事情就是制造大量的虚假报告。这就是为什么漏洞赏金计划正在暂停或收紧规则的原因。

我使用 AI 的方式有所不同。我会让 AI 根据我的“AuthZ 异味目录”（AuthZ Smell Catalog）过度生成假设。然后，由我来完成繁重的工作。我的工作就是去证伪（kill）这些假设。

一次成功的审计并不是一份漏洞清单，而是一张被测试证伪的想法清单。

我审计了 Ory Kratos 的源代码。Kratos 处理身份和用户管理。由于它使用了多种身份和公共 API，因此是一个高风险领域。

我测试了五个假设：

  • H1：Admin API 在代码中没有授权逻辑。
  • H2：跨身份或跨租户的数据泄露。
  • H3：恢复流程中的 Token 复用。
  • H4：设置流程中的身份混淆。
  • H5：通过请求负载进行租户分配。

结果：

  • H1：已证伪。授权存在于网络边界，而非代码处理器中。这是设计使然。
  • H2：已证伪。一个中心化的数据访问层通过租户 ID 过滤所有查询。用户无法绕过这一点。
  • H3：已证伪。Token 是单次使用且有时效限制的。
  • H4：已证伪。流程与会话绑定，而非用户输入。
  • H5：已证伪。租户 ID 来自系统上下文，而非请求体。

提出了五个假设，最终零发现。这就是一次成功的审计。

给你的安全工作的两条建议：

  1. 部署层安全看起来像是缺失了安全防护。如果防护措施存在于网络层，代码看起来就会显得“赤裸”。在检查架构之前，不要轻易上报。

  2. 寻找“咽喉点”（chokepoint）。如果系统在数据层强制执行边界，那么单个处理器就不需要进行检查。与其问“这个处理器是否检查了权限”，不如问“是否有人可以在不经过咽喉点的情况下触达数据？”

使用 AI 来排除候选者。使用人类来验证幸存者。价值在于排除的过程。

Source: https://dev.to/fdjedkdlsspec/ai-assisted-authz-review-reading-permission-boundaries-in-ory-kratos-31cg

Optional learning community: https://t.me/GyaanSetuAi