拼接两个ID泄露跨租户的个人身份信息

s0ufm3l
s0ufm3l

漏洞集萃

2026年8月12日 09:42
山东

在小说阅读器读本章

去阅读

本公众号所发布的文章内容仅供学习与交流使用，禁止用于任何非法用途；如有侵权烦请告知，我们会立即删除并致歉，谢谢

在测试一个私有漏洞赏金计划时，我遇到了一个

作者: s0ufm3l
原文链接: https://medium.com/@s0ufm3l/idor-via-comma-injection-how-concatenating-two-ids-leaked-cross-tenant-pii-d5f003e594f9

简而言之：某个权限接口预期在单个POST参数中接收一个数字用户ID。发送两个以逗号分隔的ID——先是受害者的ID，然后是我自己租户中的一个有效ID——完全绕过了所有权验证。 后端处理了该请求，不仅添加了我无权操作的用户，还在响应中返回了该用户的全名、邮箱和内部租户ID。

该功能

目标应用是一个文档存储库：包含文件夹、文件，并针对它们应用了访问控制列表（ACL）。文件夹所有者可以授予其他用户 Read, Write，或 FullControl 通过“权限”面板授予其他用户权限。

在后台，该面板中的每项操作都会通过一个 JSON-RPC 风格的端点进行：

user_group_id 该字段用于告知后端应向哪个用户添加并应用 ACL。

首次尝试：被阻止（如预期）

最直观的测试是：能否添加一个不在我租户中的用户？

响应： Access Denied。很好——服务器端进行了所有权检查，确认目标用户对请求租户可见或归该租户所有。

绕过方法：

我尝试观察当在“user\_group\_id”中发送特殊字符时服务器的反应，并注意到当在参数中发送逗号时响应会有所不同；随后，我没有发送单个ID， 我发送了两个用逗号连接的 ID——先是受害者的 ID，接着是合法用户的 ID。ID 的顺序至关重要，因为我注意到服务器似乎仅检查最后一个参数是否属于我的租户：

结果被接受了。

确认信息泄露

在发送经过特殊构造的 addObjectAccess 请求后，我调用了配套方法， getObjectAcl，以读取该文件夹的访问控制列表（ACL）：

响应中现在包含了受害者账户的完整ACL条目——该账户与我的租户完全没有任何关联：

来自完全不同组织的一名用户的全名、电子邮件地址和内部租户 ID——任何能够猜出或枚举出有效 user_id ，且在其租户中至少有一个文件夹具有 FullControl 权限的文件夹。

影响

• 机密性：

泄露了与本租户无关的其他租户中用户的个人身份信息（全名、电子邮件、内部租户/用户 ID）。
* 完整性：

能够将任意外部用户添加到文件夹的访问控制列表（ACL）中，从而绕过租户隔离机制。

漏洞赏金计划的要点

• 当某个参数仅接受单个 ID 且因值未授权而被拒绝时，不要就此止步——请尝试：
• 以逗号/分号/竖线分隔的多值注入
• array ([\"victim_id\"], {\"id\": [\"a\",\"b\"]})

觉得本文内容对您有启发或帮助？
点个关注➕，获取更多深度分析与前沿资讯！

👉 往期精选

逻辑漏洞：邮箱注册 tips #11

非常用403绕过 Tips

通过路径遍历和 URL 解析差异绕过 API 网关隔离

新技术绕过文件上传