SCIM 漏洞挖掘实战指南
SCIM Hunting - Beyond SSO
2025 年 5 月 8 日 - 发布于 Francesco Lacerenza
引言
近年来,单点登录相关漏洞获得了极大关注,并出现了许多优秀的公开披露。仅举几个例子:
常见 OAuth 漏洞
通过解析差异绕过 SAML SSO 认证
在 OAuth 登录流程中使用"脏舞"进行账户劫持
等等 - 确实存在大量宝贵资源。毫不奇怪,使用自定义实现的系统受影响最大,因为将 SSO 与平台的用户对象模型集成并非易事。
然而,虽然 SSO 经常占据中心舞台,但另一个标准往往被忽视测试 - SCIM(跨域身份管理系统)。在本博客文章中,我们将深入探讨其核心方面以及在我们测试客户实现时经常发现的不安全设计问题。
目录
SCIM 101
漏洞挖掘
额外关注领域
结论
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 操作的安全公告。这是一个支持各种身份验证标准的开源身份解决方案,如 OAuth、SAML、OIDC 等。当然,SCIM 也被包含在内,但作为一项服务,意味着 Casdoor 也允许外部参与者操作其用户池。
Casdoor 使用了 elimity-com/scim 库,该库根据标准默认在其配置中不包含身份验证。因此,使用此库定义和暴露的 SCIM 服务器保持未经身份验证状态。
利用实例需要与配置域匹配的电子邮件。可使用 SCIM POST 操作创建匹配内部电子邮件域和数据的新用户。
然后,使用新的管理员用户 admin2:12345678 验证到 IdP 仪表板。
注意:维护者发布了一个新版本,其中包含修复程序。
SCIM 令牌管理
[*] IdP 端问题由于 SCIM 密钥允许对服务提供商执行危险操作,因此应在设置后保护它们免遭提取。在配置的应用程序上测试或编辑 IdP SCIM 集成时,如果连接器 URL 与先前设置的 URL 不同,应需要输入新的 SCIM 令牌。
[*] SP 端问题 SCIM 令牌创建和读取应仅允许高特权用户。以用于管理它的 SP 端点为目标,并寻找授权问题,或使用漂亮的 XSS 或其他漏洞对其进行攻击,以在平台中升级访问级别。
不必要的用户重新配置回退
由于实时用户访问管理是 SCIM 的核心,因此也值得寻找导致已取消配置的用户返回并具有对 SP 访问权限的回退。
内部属性操纵
在将身份同步外包给 SCIM 时,选择将 SCIM 对象中的哪些内容复制到新的内部对象变得至关重要,因为错误可能源于"过度"的属性允许。
[*] 示例 1 - 内部角色权限提升客户端支持通过 SCIM 端点配置和更新 Okta 组和用户。它将 Okta 组转换为具有自定义标签的内部角色,以引用"Okta 资源"。特别是,函数 resource_to_access_map 从提供的 SCIM 组资源构建了未经验证的访问映射。
[*] 示例 2 - SCIM 到用户映射中的批量分配其他内部属性操作可能取决于对象映射策略。
验证绕过
此类别包含所有由于 SCIM 事件引起的更新未应用所需的内部用户管理流程而产生的漏洞。
[*] 示例 - 相同但绕过代码 SCIM 电子邮件更改未触发其他电子邮件更改操作所需的典型确认流程。攻击者可以请求向其电子邮件发送验证码,使用 SCIM 将电子邮件更改为受害者电子邮件,然后兑换验证码从而验证新的电子邮件地址。
账户接管
在多租户平台中,SSO-SCIM 身份应链接到底层用户对象。虽然它不是 RFC 的一部分,但需要管理用户属性以最终触发平台的验证和所有权检查流程。
[*] 示例 - 相同但不同客户端允许 SCIM 操作更改用户的电子邮件并执行账户接管。每次创建或更新 SCIM 用户时都会调用 set_username 函数。
额外关注领域
有趣的 SCIM 操作语法
根据 rfc7644,Path 属性定义如下:
当 path 属性为 OPTIONAL 时,当它是执行逻辑的一部分时,应仔细管理 nil 可能性。
批量操作顺序评估
由于可能支持批量操作,这些实现中可能会出现特定问题:
竞争条件 - 排序逻辑可能不包括对每个步骤中触发的额外过程的推理
缺少循环引用保护
JSON 互操作性
由于 SCIM 采用 JSON 进行数据表示,JSON 互操作性攻击可能导致挖掘列表中的大多数问题。
结论
作为 SSO 的扩展,SCIM 有潜力在特定情况下启用关键利用。如果您正在测试 SSO,SCIM 也应该在范围内!
最后,SCIM 实现中大多数有趣的漏洞需要深入了解应用程序的授权和身份验证机制。真正的价值在于识别 SCIM 对象与映射的内部用户对象之间的差异,因为这些差异通常会导致有影响的发现。更多精彩内容 请关注我的个人公众号 公众号(办公 AI 智能小助手)对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号(网络安全技术点滴分享)
公众号二维码
公众号二维码







评论