SCIM安全漏洞挖掘指南

SCIM Hunting - Beyond SSO

08 May 2025 - Posted by Francesco Lacerenza

引言

近年来，单点登录相关漏洞获得了惊人关注，并出现了许多优秀的公开披露。仅举几个例子：

常见OAuth漏洞
以任意用户身份登录：通过解析差异绕过SAML SSO认证
在OAuth登录流程中使用"脏舞"进行账户劫持

等等 - 这里有很多宝贵资源。毫不奇怪，使用自定义实现的系统受影响最大，因为将SSO与平台的用户对象模型集成并非易事。

然而，虽然SSO经常占据中心舞台，但另一个标准往往未被充分测试 - SCIM。在本博客文章中，我们将深入探讨其核心方面以及我们在测试客户实现时经常发现的不安全设计问题。

SCIM 101

SCIM是一个旨在自动化跨系统用户账户配置和取消配置的标准，确保连接部分之间的访问一致性。该标准在以下RFC中定义：RFC7642、RFC7644、RFC7643。

虽然它并非专门设计为IdP到SP的协议，而是用于云环境的通用用户池同步协议，但现实场景主要将其嵌入在IdP-SP关系中。

核心组件 简而言之，该标准定义了一组由服务提供商公开的RESTful API，其他参与者应可调用这些API来更新用户池。

它提供具有以下操作集的REST API来编辑托管对象：

创建：POST https://example-SP.com/{v}/{resource}
读取：GET https://example-SP.com/{v}/{resource}/{id}
替换：PUT https://example-SP.com/{v}/{resource}/{id}
删除：DELETE https://example-SP.com/{v}/{resource}/{id}
更新：PATCH https://example-SP.com/{v}/{resource}/{id}
搜索：GET https://example-SP.com/{v}/{resource}?<SEARCH_PARAMS>
批量：POST https://example-SP.com/{v}/Bulk

因此，我们可以将SCIM总结为一组可用于对表示用户身份的一组JSON编码对象执行CRUD操作的API。

核心功能 如果您想查找SCIM实现中的漏洞，以下是在审计期间需要审查的核心功能列表：

服务器配置和认证/授权中间件 - SCIM未定义其认证/授权方法，因此始终是自定义的
SCIM对象到内部对象的映射功能 - 后端如何将SCIM对象转换/链接到内部用户和组对象
操作执行逻辑 - 身份相关对象中的更改通常会触发应用程序流程

注意影响 作为直接的IdP到SP通信，大多数由此产生的问题需要一定级别的IdP或SP访问权限。因此，攻击的复杂性可能会降低您的大多数发现。

相反，在SCIM用户可能缺乏常见租户隔离逻辑的多租户平台中，影响可能会急剧上升。

漏洞挖掘

以下是在审计SCIM实现时应寻找的一些有价值的漏洞示例。

认证绕过 几个月前，我们发布了关于Casdoor IdP实例中未经认证的SCIM操作的安全公告。这是一个支持各种认证标准的开源身份解决方案。当然，SCIM作为一项服务包含在内，这意味着Casdoor将允许外部参与者操作其用户池。

Casdoor使用了elimity-com/scim库，该库默认情况下不包含其配置中的认证。因此，使用此库定义和公开的SCIM服务器保持未经认证状态。

利用实例需要匹配配置域的电子邮件。SCIM POST操作可用于创建匹配内部电子邮件域和数据的新用户。

然后，使用新的管理员用户admin2:12345678认证到IdP仪表板。

注意：维护者发布了新版本，其中包含修复程序。

虽然这是一个非常简单但关键的问题，但可以在经过认证的实现中找到绕过。在其他情况下，服务可能仅在内部可用且不受保护。

SCIM令牌管理 [*] IdP端问题由于SCIM密钥允许对服务提供商执行危险操作，因此应保护它们免受设置后发生的提取。如果连接器URL与先前设置的URL不同，则应在配置的应用程序上测试或编辑IdP SCIM集成需要新的SCIM令牌输入。

发现一个著名的IdP正在向/v1/api/scim/Users?startIndex=1&count=1发出SCIM集成测试请求，使用旧密钥，同时接受新的baseURL。

[*] SP端问题 SCIM令牌创建和读取应仅允许高特权用户。目标用于管理它的SP端点，并查找授权问题，或使用漂亮的XSS或其他漏洞来升级平台中的访问级别。

不需要的用户重新配置回退 由于实时用户访问管理是SCIM的核心，因此也值得寻找导致取消配置的用户重新获得对SP访问权限的回退。

内部属性操作 在将身份同步外包给SCIM时，选择将SCIM对象中的哪些内容复制到新的内部对象变得至关重要，因为"过度"的属性允许可能会导致漏洞出现。

[*] 示例1 - 提升到内部角色一个客户端支持通过SCIM端点配置和更新Okta组和用户。

它将Okta组转换为具有自定义标签的内部角色，以引用"Okta资源"。特别是，函数resource_to_access_map从提供的SCIM组资源构建了一个未经验证的访问映射。

实现问题在于，role_list中的角色名称是在从第三方源传递的Id属性上构建的。

后来，另一个函数更新了从SCIM事件构造的Role对象，没有进一步检查。因此，可以通过在SCIM组ID中匹配其名称来覆盖平台中的任何现有资源。

[*] 示例2 - SCIM到用户映射中的批量分配其他内部属性操作可能取决于对象映射策略。

验证绕过 此类别包含所有由于SCIM事件引起的更新未应用所需的内部用户管理流程而出现的漏洞。

一个相关的有趣发现是Gitlab绕过电子邮件验证。我们在评估期间也发现了涉及在代码验证过程中绕过的类似案例。

[*] 示例 - 相同但带有代码绕过 SCIM电子邮件更改未触发其他电子邮件更改操作所需的典型确认流程。

攻击者可以请求验证代码到他们的电子邮件，使用SCIM将电子邮件更改为受害者电子邮件，然后兑换代码，从而验证新的电子邮件地址。

账户接管 在多租户平台中，SSO-SCIM身份应链接到底层用户对象。虽然它不是RFC的一部分，但需要管理用户属性以最终触发平台的验证和所有权检查流程。

一个公共示例案例是CVE-2022-1680 - 通过SCIM电子邮件更改的Gitlab账户接管。以下是在我们一个客户端中发现的非常相似的实例。

[*] 示例 - 相同但不同一个客户端允许SCIM操作更改用户的电子邮件并执行账户接管。

函数set_username在每次创建或更新SCIM用户时被调用。

underlying_user应为nil，从而根据isAuthzed阻止更改。在我们的特定情况下，授权函数未保护处于特定状态的用户免遭接管。SCIM可用于强制更改受害者用户的电子邮件，并在将其添加到租户后接管账户。如果与经典的"强制租户加入"问题结合，可以形成一个漂亮的链。

此外，由于平台未保护免受多SSO上下文切换，一旦使用新电子邮件认证，攻击者可以访问用户所属的所有其他租户。

额外关注领域

有趣的SCIM操作语法 根据rfc7644，Path属性定义为：

当path属性是执行逻辑的一部分时，应仔细管理其nil可能性。

放置一个catch-all默认值可能允许另一种PatchOp消息语法仍然命中受限情况之一，同时跳过检查。

批量操作顺序评估 由于可能支持批量操作，这些实现中可能出现特定问题：

竞争条件 - 排序逻辑可能不包括对每个步骤中触发的额外过程的推理
缺少循环引用保护 - RFC7644明确讨论了循环引用处理

JSON互操作性 由于SCIM采用JSON进行数据表示，JSON互操作性攻击可能导致挖掘列表中描述的大多数问题。

一旦发现SCIM实现中使用的解析库，请检查其他内部逻辑是否在存储JSON序列化时依赖，同时使用不同的解析器进行比较或解组。

尽管是一种相对简单的格式，但JSON解析器差异可能导致有趣的案例。

结论

作为SSO的扩展，SCIM有潜力在特定情况下启用关键利用。如果您正在测试SSO，SCIM也应该在范围内！

最后，SCIM实现中最有趣的漏洞需要深入了解应用程序的授权和认证机制。真正的价值在于识别SCIM对象和映射的内部用户对象之间的差异，因为这些差异通常会导致有影响的发现。