来Track安全社区投稿~
赢千元稿费！还有保底奖励~（https://bbs.zkaq.cn）
某组织在实时聊天系统的设置中存在错误配置，允许未经身份验证的用户访问与客户支持代理的聊天历史记录。
我们最近对使用实时聊天系统的各类组织进行了安全研究。作为研究结果披露的一部分，我们希望分享一个发现，该发现突显了这些系统在设置和操作方面存在的安全隐患。
在进行安全研究时，我们主要关注两种情况：
在本次研究中，我们发现了一个配置错误，我们认为这种情况可能在其他公司中也较为普遍。
三种不同的实时聊天系统
当你与实时聊天系统互动时，最常见的是以下三种系统之一： 基于生成式AI的聊天机器人：该系统基于客户数据和FAQ（常见问题解答），根据用户输入回答问题。（系统 1） 简单的FAQ机器人：仅基于内部和外部文档提供回答。（系统 2） 实时客服聊天系统：用户直接与客服人员互动。（系统 3）我们主要研究那些会接收或存储用户相关信息的聊天机器人和实时客服系统，比如用户消息、历史订单等。这些数据通常存在于系统 1 和系统 3 中。对于这类系统，组织在存储用户信息时必须实现某种形式的身份验证机制，以便获取当前用户的信息，并用这些信息与系统交互或存储用户提供的数据。
实时聊天系统与身份验证
几乎所有实时聊天系统的服务提供商都内置了身份验证功能，允许组织跟踪用户的消息和信息，以供日后参考。一种常见的身份验证机制是，组织从其系统中提取已登录用户的ID或电子邮件，并生成一个加盐哈希值。然后，这个哈希值通过API调用发送给实时客服服务提供商，用于验证聊天的身份。以下是 HelpShift 用户身份验证文档中该机制的示例：:![]( "null")
如流程所示，组织使用服务提供商（本例中为 HelpShift）提供的预生成密钥（Secret Key），基于 user_id 或 email 生成 HMAC（哈希消息认证码）。然后，这个 HMAC 通过 SDK 返回给 HelpShift 进行验证。类似的身份验证机制也存在于其他服务提供商中，比如 Intercom。例如，使用 Intercom 的 HackerOne，通过服务器端函数为已登录用户生成一个 Intercom 令牌，并在响应中返回该令牌，以初始化 SDK。![]( "null")
这在正确实施的情况下，可以较为安全地将用户聊天会话集中存储和跟踪。然而，与实现 SaaS 解决方案常见的问题一样，这里可能存在配置错误。配置错误实例：未经身份验证即可访问数百万用户的聊天记录
在调查实时聊天系统时，我们主要关注那些允许与客服人员交流且为已认证用户存储聊天历史记录的系统。我们的主要目标是找到读取其他用户聊天记录的方法，无论是通过服务提供商的漏洞，还是组织端的配置错误。在测试不同组织时，我们分析了组织如何为经过身份验证的聊天会话生成 user_hash 或 auth_token。尤其是这本应在服务器端完成，我们很好奇是否能泄露密钥或发现身份验证机制的缺陷。理想情况下，这一过程不应受到攻击者的控制。在我们测试的某个组织中，我们注意到，该组织基于来自 cookie 的用户电子邮件生成 user_hash / auth_token 等效信息。向他们的消息端点发送请求，并附上我们“目标”的电子邮件地址，会返回一个身份验证令牌（auth token），然后可以使用此令牌与服务提供商的 API 交互，读取用户发送给客服团队的所有聊天消息。![]( "null")
![]( "null")
通过 cookie _svpt 传入的 user_id 被泄露的用户认证令牌。通过研究服务提供商（HelpShift）的 API，我们可以使用目标用户的邮箱和从组织获取的 auth_token 发送如下请求，以获取聊天记录:![]( "null")
在这种情况下，Authorization 头只是用于应用认证的 platform-id 的 base64 编码值。成功的调用会返回目标用户的完整聊天记录。![]( "null")
我们迅速将此漏洞报告给受影响的组织，该组织已修补了其实例。尽管这只是一个案例，但我们认为还有更多组织受到此类配置错误的影响。归根结底，安全地 生成有效的身份验证令牌是实施这些聊天系统的组织的责任，而非服务提供商的责任。声明：⽂中所涉及的技术、思路和⼯具仅供以安全为⽬的的学习交流使⽤，任何⼈不得将其⽤于⾮法⽤途以及盈利等⽬的，否则后果⾃⾏承担。所有渗透都需获取授权！
如果你是一个网络安全爱好者，欢迎加入我的知识星球：zk安全知识星球,我们一起进步一起学习。星球不定期会分享一些前沿漏洞，每周安全面试经验、SRC实战纪实等文章分享，微信识别二维码，即可加入。
![]()
