AI聊天机器人IDOR漏洞分析：基于上下文信任的越权攻击实战

今天，我想分享一个曾困扰我四天的漏洞案例。问题的核心，竟然源于一个人工智能聊天机器人对上下文的过度信任。

故事的起因是我在目标平台发现新增了一个AI聊天机器人功能。这个机器人不仅能回答关于功能的问题，还能在用户的授权下执行一些操作。

我端起咖啡，开始测试。为了简化测试目标，我选择了一个名为“ShopFire”的服务，该服务允许用户创建产品商店。我打开了聊天机器人界面，并向它发送了一条指令：

将此产品名称更改为“test1”；https://target.com/24988wsaaas3a

随后，我通过代理工具捕获了发出的请求：

POST /api/chat/reply HTTP/2
Host: target.com
Cookie: ...
Origin: https://target.com
Referer: https://target.com/03223/product=24988wsaaas3a
Content-Type: application/json

{
  “message”: “change this product to name \”test1\”; https://target.com/24988wsaaas3a",
  “current_url”: “https://target.com/24988wsaaas3a/products/edit”
}

请求发送后，聊天机器人会提供“确认”或“否认”两个选项让用户选择。

由于我注意到请求中的多个参数（如 Referer、current_url 和 message）都可能被操控，我立刻切换到一个新的测试账户进行验证。初次测试便证实了我的猜想：这里存在一个不安全的直接对象引用（IDOR）漏洞。

这意味着，攻击者只需将请求中的 Referer 和 current_url 参数修改为任意受害者的产品编辑页面链接，就能诱导AI机器人修改该用户的产品信息，而无需经过任何身份验证。发现这个利用AI进行越权操作的问题后，我立即提交了漏洞报告。

然而，事情并没有就此结束。几天后，目标平台的安全团队回复了我。他们表示无法在内部复现这个问题，并要求我尝试修改他们指定的测试商店以证明漏洞的有效性。

我返回目标平台进行复现，却遇到了新的情况。在使用另一个账户尝试攻击一个“干净”的商店（即该商店从未与AI机器人有过交互）时，AI给出了如下回复：

我还是找不到这个产品的店铺，所以这个名字不能改。如果您有其他产品或商店，请提供详细信息或让我知道您的下一个请求。

核心问题出现了：为什么漏洞对某些账户有效，对另一些却无效？在我自己的账户间测试时，攻击是成功的。我花费了接下来的三天时间，试图理解这背后的逻辑——是IP信任机制，还是其他原因？

直到第四天，我在阅读一篇关于利用奇特密码重置功能劫持账户的漏洞分析文章时受到了启发。那篇文章的作者通过深入理解后端逻辑，将一个看似古怪的漏洞变得清晰明了。

这促使我重新审视自己的发现，并提出了一个关键假设：如果AI机器人判断权限的依据，并非实时校验，而是基于历史聊天上下文的缓存呢？

漏洞的根本原因正在于此：

1. 当合法用户（受害者）首次向AI机器人咨询某个特定产品（如产品ID: 24988wsaaas3a）时，AI会查询后台，确认该用户拥有此产品的操作权限。这一次成功的查询记录（包含产品ID、店铺ID及权限状态）会被缓存在服务器的数据库中。
2. 当攻击者随后向AI发送恶意请求，并篡改参数指向同一个产品ID时，AI的验证逻辑并非去实时校验攻击者的身份，而是去查询历史缓存。
3. 由于缓存中已经存在一条记录，表明“产品ID 24988wsaaas3a 属于某个有效店铺，且可被操作”，AI机器人便盲目地信任了这条缓存记录，并执行了攻击者的修改指令，导致了越权攻击的发生。

简单来说，这是一个典型的上下文状态信任漏洞。AI机器人错误地将一次有效的、经过身份验证的上下文查询结果，应用于后续所有未经身份验证的、但包含相同对象ID的请求上。

每一个棘手的漏洞都是一次深入学习的机会。它迫使你超越表面现象，去探究系统底层的运作逻辑。保持耐心，持续挖掘，最终的理解会带来巨大的收获。