2026-05-16 06:04:58 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文披露了一个SaaS云平台访问控制漏洞，攻击者可通过篡改/adds3ai_user.php端点id参数任意创建并持续控制云AI账户。漏洞本质是服务器完全信任客户端提供的UUID参数而未验证所有权，属于典型IDOR漏洞。文章详细描述了利用步骤、潜在危害（未授权资源配置、持续访问、绕过控制模型），并提出根本解决方案：服务器端生成标识符、绑定会话、强制授权验证、监控异常操作。 综合评分： 87 文章分类： 漏洞分析,WEB安全,应用安全,云安全,安全建设

cover_image

访问控制失效：单个参数如何导致未经授权的云帐户创建和持续访问

haidragon haidragon

安全狗的自我修养

2026年5月14日 12:13 湖南

在小说阅读器读本章

去阅读

官网：http://securitytech.cc

#

介绍

在对 SaaS 云平台进行安全测试时，我发现了一个有趣的授权漏洞，该漏洞允许任何未经身份验证或权限较低的用户通过操纵单个 URL 参数来创建并持续控制基于云的 AI 用户帐户。

本文详细介绍了漏洞的发现、利用、影响和修复过程。为遵循负责任的信息披露原则，我特意省略了目标域名以及任何与受影响平台相关的识别信息。

背景

现代SaaS平台通常依赖UUID（通用唯一标识符）来管理用户帐户、会话和资源。UUID的设计初衷是使其具有不可预测性，但它们本身并非安全机制。当应用程序将客户端提供的UUID视为可信输入，而未验证其所有权或授权时，就会出现一类被称为“不安全直接对象引用”（IDOR）和“访问控制失效”的漏洞，这两种漏洞均出现在OWASP十大安全漏洞列表中。

这一发现是服务器端验证缺失的典型案例。

漏洞

受影响的端点负责在平台上配置新的“S3 AI 用户”帐户。它通过 GET 请求接受单个参数：

GET&nbsp;/add_s3_ai_user.php?id=&nbsp;<user_id>

正常情况下，该id参数应包含服务器为当前已认证用户生成的 UUID。预期行为是验证以下内容：

提供的标识符属于已认证的会话。
该标识符是由服务器合法颁发的。
请求者拥有创建或访问该资源的权限。

实际上，这些检查都没有执行。后端完全信任客户端提供的任何值，并创建了一个与该任意标识符关联的账户。

重现步骤

利用流程很简单：

步骤 1 — 观察合法请求。登录测试帐户后，我注意到应用程序使用服务器颁发的有效 UUID 调用了端点：

GET&nbsp;/add_s3_ai_user.php?id=4f8a2b1c-9d3e-4f7a-b2c1-8e6d9f0a1b2c

步骤 2 — 篡改参数。我使用拦截代理，将 UUID 替换为我选择的任意字符串：

GET&nbsp;/add_s3_ai_user.php?id=12345

步骤 3 — 转发请求。服务器响应成功，表明已使用攻击者提供的标识符创建了一个新的 S3 AI 用户帐户。

步骤 4 — 重用标识符。使用相同的任意字符串重新发送请求，即可访问之前创建的帐户。该标识符保存在服务器端，可以无限期地重复使用。

换句话说：攻击者不仅可以随意创建账户，而且还能持续控制这些账户。

为什么这很重要

乍一看，创建一个“以随机字符串作为 ID 的账户”似乎无害。然而，其安全隐患远不止于此：

未经授权的资源配置。任何行为者都可以在未经合法授权的情况下创建云端 AI 用户帐户，从而可能消耗后端资源、存储配额或与平台基础设施相关的计算能力。
持续的未经授权访问。由于攻击者选择了标识符，他们可以随时返回并继续使用该帐户。与服务器生成的 UUID 不同，攻击者选择的字符串对其完全公开。
绕过访问控制模型。该端点完全绕过了平台预设的授权模型。它既没有所有权检查，也没有会话到资源的绑定，更没有验证标识符的来源。
潜在的攻击转移风险。根据人工智能用户帐户关联的内容（存储桶、API密钥、模型访问权限、计费），攻击者可以利用这些帐户访问相关服务或进一步提升权限。
滥用和拒绝钱包攻击风险。自动化批量创建账户可能被用于耗尽后端资源、增加云成本，或发起进一步攻击，例如垃圾邮件、数据抓取或模型滥用。

根本原因分析

根本问题在于对客户提供的信息过于信任。该应用程序做出了三个错误的假设：

从客户端接收到的参数id始终是服务器先前发出的参数。
那些类似 UUID 的字符串本质上是可信的。
拥有身份识别码的行为等同于获得使用该身份识别码的授权。

在对抗性环境中，这些假设均不成立。服务器是唯一能够权威地确定所有权和授权的实体，然而在这里，这项责任实际上被委托给了客户端。

建议的补救措施

为妥善解决此类问题，建议采取以下措施：

标识符只能在服务器端生成。在创建流程中，切勿从客户端接收帐户或资源标识符。服务器应生成标识符并将其返回给客户端。
将资源绑定到已认证的会话。每个帐户或资源都应与已认证用户建立明确的所有权关系，并在数据库层和应用层强制执行。
对每个请求都强制执行授权。在对资源执行任何操作之前，请验证已认证用户是否拥有访问或修改该资源的权限。
拒绝未知或攻击者伪造的标识符。如果传入的标识符与服务器颁发的、与当前会话关联的记录不匹配，则应直接拒绝该请求。
增加监控和速率限制功能。应检测并限制可疑模式，例如快速创建账户、来自异常来源的标识符或反复访问非自有资源。
审计相关端点。如果一个端点出现这种模式，其他端点通常也会出现。因此，有必要对应用程序的授权模型进行更全面的审查。

经验教训

这一发现提醒我们，授权并非可有可无的功能，而是所有涉及用户数据或资源的端点都必须具备的基础属性。UUID、随机字符串和晦涩的参数本身并不能提供真正的安全保障。关键在于服务器是否验证请求者是否拥有执行其请求操作的权限。

本案例的共同启示：

将客户提供的每个标识符都视为不可信输入。
永远不要想当然地认为“前端会发送正确的值”。
测试创建流程时，务必像测试读取或删除流程一样仔细。它们同样重要。
漏洞赏金猎人和安全测试人员应该始终关注标识符在应用程序中的流动方式，以及是否在每个步骤中都强制执行所有权。

披露时间表

该问题已通过相关供应商的负责任披露渠道报告，并已得到确认。根据负责任披露原则，有关具体平台的详细信息已被隐去。

结语

访问控制失效仍然是现代 Web 应用程序中最具影响力和最常见的漏洞类型之一，并且它持续位居 OWASP 漏洞排行榜榜首并非偶然。像这样的案例表明，利用漏洞的门槛通常非常低：只需篡改一个参数，无需绕过身份验证，无需使用复杂的有效载荷，仅仅服务器端缺少一项检查即可。

如果你正在构建面向云的应用程序，那么你能养成的最有价值的习惯就是，对于每个端点都要问自己：“服务器如何知道这个用户有权执行此操作？”如果你无法自信地回答这个问题，那么你很可能刚刚发现了下一个 bug。

感谢阅读。如果您觉得这篇文章有用，欢迎分享给从事应用安全或Web开发的其他人员。保持好奇心，并时刻关注id参数变化。

公众号:安全狗的自我修养
vx:2207344074
http://gitee.com/haidragon
http://github.com/haidragon
bilibili:haidragonx

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全狗的自我修养 haidragon haidragon《访问控制失效：单个参数如何导致未经授权的云帐户创建和持续访问》