Sygnia：AI写全了每个安全控制，唯独信任决策‘翻车’致客户数据外泄

一家管理数十亿美元客户资产的金融服务公司，委托事件响应公司 Sygnia 对其客户入职应用进行渗透测试。这套应用几乎全部由 Claude 生成的代码构建，处理政府身份证件、身份验证数据、支付细节和社会安全号码。结果令整个安全团队感到意外：一名普通申请人，竟然能够直接够到另一名申请人的完整档案，而系统里该有的安全控制一个都没少。

这不是又一个AI写出的不安全工作代码案例。恰恰相反，AI的产出在安全控制列表上几乎无可挑剔。临时访问令牌、令牌过期时间、速率限制、审计日志、会话恢复、可疑活动检测——所有标准控制措施都规规矩矩地写在了代码里。但就是这样一个“控制齐全”的系统，让不该获得权限的人，悄无声息地越过了权限边界。

Sygnia 在调查报告中直接点明了问题的根源：控制没有缺失，控制包在了错误的信任决策外面。“问题不在于系统缺少安全控制，”报告写道，“而在于这些控制是围绕着一个错误的信任决定搭建的。”需要弄清楚的是，访问令牌到底凭什么被发放、被恢复？系统给出的答案，让整个防线从起点就偏了。

出错的那个决定

这套应用解决了一个很实际的业务问题：准客户启动申请后又离开，在注册账号之前需要恢复进度，而且系统不能依赖密码。Claude为这种场景产出了一套临时访问模型。递出令牌的依据非常直接——持有申请人的全局唯一标识符（GUID），就足以证明你有权拿到令牌。GUID本质上是记录的唯一编号，用来标识“这笔申请是谁的”，却绝不是用来验证“当前这个请求是不是申请人本人操作的”凭证。

于是，在这种设计下，无论请求来自哪台设备、哪个会话，也不管发起者是否掌控着已验证的联系渠道或身份凭证，只要在请求里带上了某个申请人的GUID，系统就会发放或恢复对应申请人的访问令牌。Sygnia 直接把这种模式定性为：“GUID成了一个持有即授权的秘密记号（Bearer secret）。”意思是，持有这个标识符的人，就被系统直接当成了申请人本人。

谁掌握了另一个申请人的GUID，就能看到对方的姓名、联系方式、申请状态、财务细节、身份验证数据、支付信息和社会安全号码。更值得注意的，还有联名申请人（co-applicant）的数据。他们本人的资料之所以出现在系统里，仅仅是因为被其他申请人列入了申请。这个漏洞不仅让主动申请者的隐私暴露，还殃及了被动卷入的无辜第三方。

当每个控制都正确，却没有一个控制回答该回答的问题

安全团队很容易掉进一个惯性陷阱：拿着安全控制对照表逐项打勾。临时令牌，有。过期机制，有。速率限制，有。审计日志，有。会话恢复逻辑，有。异常行为检测，有。但在这次调查中，每一项控制都是在令牌发放之后的流程里起作用，没有一项干预在“该不该发令牌”这个最关键的出发点。

一个短期有效的令牌，一旦发给了错误的人，在它失效前的几秒、几分钟内，依然足以拖出大量敏感数据。审计日志在事后才记录下访问轨迹，它能帮助后续调查追溯损失，却阻止不了数据在那一刻被拉走。速率限制和异常检测或许能注意到异常的访问频率或行为模式，但假如攻击者只尝试寥寥几次请求，并且每次请求使用的都是正确的GUID，这些检测机制就会温和地将其视为正常业务。

Sygnia 的研究人员在报告中提出了一个看似简单，却贯穿整个信任模型的问题：“在后台发放或恢复一个申请人访问令牌之前，到底必须证明什么？”正是对这个问题的回答，决定了系统边界的实际位置。如果答案是“证明你有GUID”，那么所有的后续控制都只是在给一个错误的授权决定加装围栏。

扫描工具为何集体失声

静态应用安全测试（SAST）工具在这个漏洞面前集体保持了沉默。它们的工作方式是在代码中搜寻不安全的编码模式和不安全的数据流。而这个缺陷不属于这两类。它既不是不安全的 API 使用，也没有在数据流转上违反任何典型规则。它藏在一整套合规的框架约定里，老老实实通过了基础检查。漏洞的根不是一行代码，而是架构层面关于“将信任放在谁身上”的选择。

负责本次评估的 Sygnia 渗透测试员扎克·米德（Zach Mead）留下了高度浓缩的判断：“能工作的代码，不等于安全的代码。”接下来他进而解释这个现象对AI生成代码的普遍启示：“AI生成的代码可能编译通过，遵循熟悉的框架约定，甚至顺利通过基础检查，却依然会在信任假设上犯下根本性的错误。”这种错误不会让应用崩溃，不会触发异常警报，它会安静地运行，直到被一次认真的渗透测试翻开。

把“能够运行”等同于“可以上线”是一条危险的路。AI擅长在确定的模式里生成符合惯例的代码，但安全常常取决于系统在特定上下文里对“谁可被信任”这个问题的判断。而这份判断力，还不能由代码生成模型代劳。当整个应用几乎全由AI构建，人类审查者的任务就不再是检查控制列表的长度，而是反复拷问那个核心问题：凭什么这次访问是被允许的？

米德的结论呼应了整起事件的真正教训：控制从来不是越多越安全，关键在于这些控制所保护的信任根基，是否放对了位置。在这家金融服务机构的例子里，AI把信任放在了记录编号上，而现实世界的安全需求要的是对身份、设备和会话的连续验证。所有后续的安全投入，都变成了建立在沙丘上的围墙。