文章总结： 本文剖析nOAuth攻击，指出EntraID未经验证邮件与SaaS应用误用邮件声明作标识符的缺陷可致跨租户账户劫持。测试显示约9%的应用存在漏洞，攻击低门槛且难检测。建议开发者遵循OIDC规范使用issuer和subject声明而非邮件识别，并指出客户端缺乏有效防御，仅能依赖供应商修复。
综合评分： 90
文章分类： 漏洞分析,云安全,应用安全
nOAuth攻击剖析：Entra跨租户SaaS应用面临账户完全劫持风险
Dubito
云原生安全指北
2026年1月12日 09:12
江苏
注1：本文翻译自 Semperis – Eric Woodruff 的文章《nOAuth Abuse Alert: Full Account Takeover of Entra Cross-Tenant SaaS Applications》[1]，可点击文末“阅读原文”按钮查看英文原文。
注2：该文章后续针对跳转至 Microsoft 365 研究存在新的进展，详见同期发布的另一篇文章。
全文如下：
一、主要发现
- • 在测试的104个应用程序中，Semperis发现其中有9个（约9%）易受nOAuth攻击滥用。
- • 由于此滥用方法已被公开披露，实施nOAuth攻击的难度很低。
- • nOAuth攻击利用了跨租户漏洞，可能导致SaaS应用程序的数据泄露、攻击者持久化驻留以及横向移动。
- • 对于存在漏洞的应用程序的客户而言，此类攻击难以检测，且客户自身无法进行防御。
- • Semperis的研究人员将此漏洞评级为潜在的严重级别，原因是攻击复杂度低、检测和防御困难。
nOAuth漏洞暴露了存在漏洞的软件即服务（SaaS）应用程序中的一个关键身份验证缺陷。攻击者只需获得一个Entra租户（这是一个很低的门槛）以及目标用户的电子邮件地址，就可以接管该用户在易受攻击应用程序中的账户。此后，攻击者便能访问目标用户在该应用程序内有权访问的所有数据。
我们已于2024年12月将我们的发现及时报告给了相关应用程序供应商和微软安全响应中心（MSRC）。MSRC确认收到报告并创建了案例93209。2025年3月，我们通知MSRC计划公开披露此事。MSRC于2025年4月关闭了该案例。在2025年5月至6月期间，我们继续联系存在漏洞的应用程序供应商，并将详细信息同步给了MSRC。2025年6月，我们收到MSRC的反馈，重申供应商应遵循相关建议，不遵循的供应商可能会被从Entra应用程序库中移除。
检测到利用nOAuth的攻击非常困难，甚至不可能实现。除了要求应用程序供应商提供更新以使应用程序免疫于nOAuth攻击外，客户没有可用的修复或缓解方案。鉴于这种攻击的简单性、检测的复杂性以及目前仍存在受影响的应用程序，Semperis认为此漏洞对Entra ID客户构成了严重风险。
本文详细介绍了Semperis安全研究团队对nOAuth的探索，重点关注微软Entra应用程序库中的应用。我们发现了九个存在漏洞的应用程序，其中包括可能包含个人身份信息（PII）的应用程序。
二、什么是 nOAuth？
2023年6月20日，Descope公司的Omer Cohen公开披露了题为“nOAuth：微软OAuth配置错误如何导致完全账户接管[2]”的信息。导致nOAuth的根本问题在于应用程序开发者使用了相对于OpenID Connect（OIDC）实现而言的反模式（anti-patterns）。这些反模式包括使用可变属性（例如电子邮件地址）作为用户标识符。由于Entra ID允许用户拥有未经验证的电子邮件地址，使用此属性可实现跨租户的用户身份冒用。在Descope的披露中，他们描述此攻击存在于Entra ID的一个“灰色地带”，其根源在于开发者遵循了这些反模式。虽然我们同意这一点，但这使得微软与SaaS应用程序供应商（ISV）的共同客户容易受到此类攻击。
针对Cohen的发现，MSRC发表了一篇关于nOAuth风险的文章：“Azure AD应用程序中潜在的特权提升风险[3]”。作为微软客户影响声明的一部分，该文章指出：
微软已识别出多个多租户应用程序，其用户使用了域名所有者未经验证的电子邮件地址。虽然未经验证的电子邮件地址不会对不利用电子邮件声明（email claims）进行授权的应用程序构成风险，但我们已通知这些应用程序所有者，并提供了如何修改其应用程序的指导（如果适用）。如果您未收到通知，则说明您的应用程序未使用来自域名所有者未经验证的电子邮件声明。 为保护可能面临特权提升风险的用户和应用程序，微软已部署缓解措施，对大多数应用程序省略来自未经验证域名所有者的令牌声明（token claims）。
—— 微软客户影响声明
微软还发布了关于迁移、停止使用电子邮件声明的具体指南。截至本文撰写时，该文章指南在微软网站上已不再提供，但您可以在其他地方找到其存档版本[4]。
三、nOAuth 攻击如何运作？
nOAuth 攻击需要三个要素：
- • 能够在 Entra ID 中设置未经验证的电子邮件地址
- • 一个允许未经验证电子邮件声明（email claim）的 App 注册
- • 应用程序对此组合存在漏洞
让我们通过一个例子来了解此类攻击可能如何发生。
3.1 在 Entra ID 中设置未经验证的电子邮件地址
Entra ID 和 Microsoft 365 服务包含一个默认租户，其域名通常为 onmicrosoft.com，例如 contoso.onmicrosoft.com。当组织配置其部署并为其服务加入自己的域名时，验证过程会使用 TXT 或 MX 记录来验证域名所有权。一旦验证通过，该域名在 Entra ID 中会被标记为已验证状态（图 1）。
图 1. Entra ID 中已验证的域名
然而，为了支持 Entra ID 中的访客用户功能，电子邮件属性的域名后缀并不需要是已验证的域名。因此，任何 Entra 租户中的任何用户都可以在 mail 属性中拥有任何电子邮件地址。
例如，图 2 显示了一个名为 Adele Vance 的用户，其 mail 属性的值与 userPrincipalName 属性相同。
图 2. 拥有已验证电子邮件地址且与 userPrincipalName 匹配的账户
我们可以执行一个简单的 PATCH 操作来更改这个 mail 属性（图 3）。
图 3. 对 Adele Vance 执行 PATCH 操作
再次执行 GET 操作显示，Adele 现在拥有了一个该租户内未经验证域名的电子邮件地址（图 4）。
图 4. Adele Vance 现在拥有一个未经验证的电子邮件地址
3.2 验证电子邮件地址更改
如果我们想在 ID token 中将未经验证的电子邮件地址验证为声明（claim），我们可以在 Entra ID 中配置一个 App 注册，将其 Redirect URI 设为 https://jwt.ms，然后将 ID token 传递给它。
对于 2023 年 6 月之后创建的 App 注册，默认情况下 Entra ID 不会发出未经验证的电子邮件声明。要修改配置以允许此行为，我们可以对 App 注册 的 authenticationBehavior 执行一个简单的 PATCH 操作，将 removeUnverifiedEmailClaim 设置为 false（图 5）。此过程在微软文章“管理应用授权行为[5]”中有文档说明。
图 5. 将 removeUnverifiedEmailClaim 设置为 false
一旦我们的 App 注册配置完成，就可以用它来模拟存在漏洞的应用程序的行为，并查看 ID token（图 6）。
图 6. 包含未经验证电子邮件地址的已解码 ID token
如果一个应用程序使用电子邮件声明作为唯一标识符，并消费了此 ID token，那么该应用程序将无法知道该用户实际上并非合法用户。
四、缓解 nOAuth 攻击
如前所述，缓解 nOAuth 攻击最终需要开发者正确实施身份验证，以确保使用一个唯一且不可变的标识符。
微软身份标准主管 Pam Dinge 在 nOAuth 披露后不久，就发表了一篇关于开发者反模式的文章。这篇文章值得一读：“错误的标识符反模式[6]”。
正如 Pam 在文章中强调的，根据 OpenID Connect 规范第 5.7 节[7]，结合使用颁发者（iss）声明和主体（sub）声明是应用程序（SP）确保用户标识符唯一且稳定的唯一方法。
在 Entra ID 中，颁发者（iss）以 Issuer URI 的形式发出，其中包含全局唯一的租户 ID（图 7）。
图 7. 唯一的颁发者声明
主体（sub）是一个成对标识符，对于每个应用程序 ID 的每个用户都是唯一的（图 8）。同样重要的是，sub 在 Entra ID 中是一个不可变的值。Entra ID 不允许对主体声明进行任何类型的声明转换或修改，从而确保其唯一性。
图 8. 唯一的主体声明
有关 Entra ID 签发的 ID token 中声明的详细信息，可在此处找到：“ID token 声明参考[8]”。
4.1 微软为缓解 nOAuth 攻击所做的更改
在 Entra ID 中，微软进行了更改，使得 2023 年 6 月之后创建的任何 App 注册，默认情况下不会发出未经验证电子邮件地址的电子邮件声明。当然，成千上万的 SaaS 应用程序在 2023 年 6 月之前就已存在，许多开发者仍然希望并需要消费电子邮件地址；许多 SaaS 应用程序希望向最终用户发送电子邮件，而通过声明（claim）消费是获取该信息的最简单方法。
为了帮助开发者，微软还引入了 xms_edov 可选声明，开发者可以用它来判断电子邮件地址是否经过验证。然而，在撰写本文时，xms_edov 声明似乎处于一种不确定的状态，这让人怀疑它是否正在被弃用。虽然微软文档表明该声明是可选的[9]，但在设置可选声明的用户界面（UI）中已不再可用。通过 Graph API 将 xms_edov 设置为可选声明是可行的，但之后会收到一条消息，提示这不是有效的可选声明（图 9）。
图 9. 设置 xms_edov 声明
实际上，开发者可以利用此信息来判断用户的电子邮件地址是否已在租户中验证（图 10）。
图 10. 针对未经验证电子邮件地址返回的 ID token 中的 xms_edov 声明
五、Semperis 最新的 nOAuth 攻击研究
5.1 Descope 关注的焦点
在 Descope 发表的研究中，重点是那些支持多个身份提供者的 SaaS 应用程序，例如 Google、Microsoft、Facebook 等（图 11）。
图 11. 多个身份提供者示例（来源：Descope）
出于可用性目的，SaaS 应用程序通常具有账户合并逻辑。例如，如果我使用 Facebook 账户注册了 Medium，然后稍后使用我的 Google 账户登录，这两个身份验证源最终会将我带到同一个 Medium 账户。
Descope 探讨的问题是，由于 Entra ID 中的任何用户账户都可以携带电子邮件声明，基于电子邮件进行账户合并的开发者可能会在不知不觉中让攻击者进入目标用户的账户。
除了微软已实施的一些功能外，Descope 建议支持账户合并功能的 SaaS 应用程序，在用户首次尝试使用不同账户源登录时中断流程，并使用一个功能来验证电子邮件所有权。我们同意这一建议。此功能可以采取电子邮件魔法链接（magic link）的形式，用户会收到一封电子邮件，要求他们在合并发生前验证所有权。
在我们自己的研究中，我们观察到这是那些被证明对 nOAuth 攻击免疫的应用程序中常见的安全实践。
5.2 Semperis 研究
2024 年深秋，作为一项探索性研究的一部分，我们在回顾 Descope 进行的研究时，决定针对一些 SaaS 应用程序进行测试。这恰好与探索微软 Entra 应用程序库的想法不谋而合。Entra 应用程序库是 Entra ID 内部的一个门户，由微软管理，允许第三方 SaaS 供应商展示那些与 Entra ID 集成的应用程序（图 12）。
图 12. 微软 Entra 应用程序库
在我们的研究中，我们检查了当时可用的所有 1,017 个 OIDC 集成，并发现其中 104 个应用程序允许用户自助注册。由于 SaaS 市场竞争激烈，供应商倾向于提供免费层级或试用版本，设置很低的使用门槛，允许您无需经过任何销售渠道即可使用和测试应用程序。我们专注于这些应用程序，不仅因为它们为安全研究提供了较低的准入壁垒，也确保我们的测试保持在道德测试的边界内。
在我们测试的每个应用程序中，我们使用一个由我们管理的“受害者”租户来配置一个我们在平台内拥有的账户。然后，我们使用一个不同的租户，即“攻击者”租户，对我们自己的受害者尝试 nOAuth 攻击。通过这种方式，我们确保测试仅影响我们控制的账户，并且仅访问我们创建的测试数据样本。
我们的研究与 Descope 的不同之处在于，我们旨在发现允许发生 Entra ID 跨租户 nOAuth 攻击的应用程序。本质上，目标（受害者）客户是拥有 Entra ID 租户的微软客户，而攻击者使用另一个不同的 Entra ID 租户来实施攻击。就我们研究中的攻击流程而言，Descope 提供的以下图表是适用的（图 13）。
图 13. nOAuth 攻击流程（来源：Descope）
然而，根据我们的关注点，SaaS 应用程序只需要支持 Entra ID 进行身份验证。虽然我们测试的几乎所有 SaaS 应用程序都支持本地用户账户，但我们发现一些应用程序还支持多个身份提供者，例如 Google 和 Entra ID，而其他应用程序则仅支持 Entra ID。
此外，我们推测，如果一个应用程序仅支持 Entra ID 进行身份验证，那么开发者很可能没有实现 Descope 提到的账户合并逻辑和电子邮件验证，因为开发者可能没有预料到会发生账户冲突的场景。
5.3 存在漏洞的应用程序
在测试的 104 个应用程序中，我们发现其中有 9 个易受 nOAuth 攻击，这大约占测试应用程序的 9%。鉴于 104 这个数字在已与 Entra ID 集成的众多 SaaS 应用程序中只是沧海一粟，您可以基于数以万计的可用 SaaS 应用程序来推断这些数字。
在我们发现存在漏洞的应用程序中，我们注意到一些关于其规模、体量和应用类型的有趣现象。我们发现了一个人力资源管理系统（HRMS）平台，它在实际应用中很可能包含大量个人身份信息（PII）。同样，我们发现一些应用程序会与 Microsoft 365 集成，以实现诸如邮件和日历访问等功能。由于这些集成使用了一套不同的访问令牌和刷新令牌组合，成功利用 nOAuth 的攻击者不仅能够访问 SaaS 应用程序的数据，还可能进一步渗透到 Microsoft 365 资源。
遗憾的是，大规模测试非常耗时。除了需要配置 Entra 租户以执行攻击外，我们还需要人工观察 SaaS 应用程序的界面，以确定攻击者是否能够访问受害者的账户。虽然大多数对此攻击免疫的应用程序通常会在首次登录时显示新的引导流程，但有些应用程序会直接将我们带入应用程序的主界面。这就要求我们检查账户信息，或尝试在应用程序内操作数据，以判断攻击者是否进入了与受害者相同的账户。
5.4 联系相关方
基于这项研究，我们向 MSRC 提交了一个案例。同时，我们也尝试联系每个拥有漏洞应用程序的独立软件供应商（ISV）的相关方。联系这些相关方后，遵循 Semperis“为善之力（Force for Good）”的原则，我们主动提出帮助他们解决其应用程序中的漏洞；有几家供应商接受了我们的帮助。在这些案例中，我们协助供应商理解问题所在，并针对他们的应用程序进行了额外的 nOAuth 攻击测试，直到问题得到解决。
六、客户防御：缺乏有效选择
最终，客户针对 nOAuth 攻击的唯一防御措施是：1）敦促供应商修复问题，或 2）弃用该 SaaS 应用程序。
由于攻击发生在受害者可控范围之外，传统的防御机制无法提供保护。这些机制包括：
- • Entra ID 中的多因素身份验证（MFA）和身份验证强度强制措施
- • 条件访问
- • 零信任网络访问（ZTNA）和任何企业的网络安全（CASB）解决方案
- • 端点检测和响应（EDR）
- • 扩展检测和响应（XDR）
6.1 nOAuth 攻击检测
尽管 SaaS 安全态势管理（SSPM）解决方案可以提供对 SaaS 应用程序的一些洞察，但它们通常关注的是暴露给平台客户的配置和安全态势，不太可能指示 nOAuth 攻击。企业级安全浏览器平台和浏览器插件也存在类似问题，它们可能有助于发现通向 SaaS 应用程序的其他后门，但不太可能发现此类攻击。
遗憾的是，这使得客户的选择非常有限：
- • 在 SIEM 平台中将 SaaS 身份验证日志与 Entra ID 日志关联分析
- • 向他们的供应商询问 nOAuth 相关情况
- • 自行执行 nOAuth 攻击测试
从 Entra ID 的角度来看，我们检查了多租户应用程序的服务主体，没有发现向客户暴露任何表明该应用程序消费未经验证电子邮件声明的属性。即使存在此类属性，也无法指示应用程序将该声明用于何种目的。
6.2 身份验证日志关联
要利用日志关联检测 nOAuth 攻击，您需要将 Entra ID 身份验证日志和 SaaS 应用程序的身份验证日志都摄入到安全信息与事件管理（SIEM）解决方案（例如 Microsoft Sentinel）中，然后在 SIEM 中对这两个日志进行关联分析。您需要查找 SaaS 平台中存在身份验证事件、但 Entra ID 中却缺失相应身份验证事件的情况（图 14）。
图 14. 理论上的日志关联
当然，将这一理论付诸实践的结果会差异很大。虽然主体（sub）是 SaaS 应用程序中的关键标识符，但在 Entra ID 的登录日志进行身份验证时并不会捕获此值。因此，SaaS 应用程序的日志中也需要包含 UPN 或 email address 等属性以便关联。同样，SaaS 供应商的身份验证日志需要能以被 SIEM 消费的方式提供。其他因素，如时间漂移和精度问题，都会增加通过日志关联检测 nOAuth 攻击的难度。
6.3 nOAuth 测试与供应商责任
客户的另一个选择是对他们使用的 SaaS 应用程序进行 nOAuth 攻击测试。在此之前，他们可以联系应用程序供应商，询问供应商是否了解 nOAuth 并已针对该攻击进行了测试。
需要注意几点：
- • SOC II 等认证并未调查此类攻击。我们发现存在漏洞的应用程序，其供应商网站上列有 SOC II 及其他认证。
- • 具体询问供应商是否已对此漏洞进行测试。我们发现有些供应商认为他们已经解决了问题，但我们仍然能够对其应用程序实施 nOAuth 攻击。
如果供应商无法明确回答此问题，客户可以对任何他们关注的应用程序执行此项测试。与安全研究人员一样，客户应确保他们在道德边界内进行测试：针对自己的用户账户进行测试，并了解他们可能与供应商签订的任何合同要求。
七、软件开发人员如何防御 nOAuth
消费电子邮件声明（email claim）的开发者应确认，他们没有将其用于用户识别。如果正在这样使用，他们应遵循微软文档中记录的步骤，遵照 OIC 规范，使用颁发者（issuer）和主体（subject）。
开发者也可以检查他们的 App 注册，以确定是否正在接收未经验证的电子邮件声明。然而，最终需要由开发者检查他们的代码，以确定电子邮件声明的使用方式。
除了从 ID token 的声明中获取，也存在其他接收电子邮件属性数据的解决方案。OIDC 规定了 UserInfo 端点，该端点在 Entra ID 中已实现。应用程序可以使用此端点在身份验证后获取有关已验证用户的信息。通过调用 UserInfo 端点，应用程序可以在身份验证后获取用户的电子邮件地址，即使该地址未经验证。此步骤确保了电子邮件声明不被用作用户的唯一标识符。
在此示例中，我们可以为拥有未经验证电子邮件地址的 Adele Vance 调用 UserInfo 端点（图 15）。作为唯一标识符的主体（subject）将与 ID token 中的主体匹配。
图 15. 调用 UserInfo 端点
已更新代码以修复 nOAuth 漏洞的开发者应在修复后测试其应用程序，确保它不易受 nOAuth 攻击。在我们与供应商的合作修复工作中，最初的修复有时并未完全解决漏洞。
在与 MSRC 就我们的发现进行沟通时，MSRC 重申开发者需要遵循相关建议，并指引我们参考其在 2023 年披露事件后发表的文章。由于应用程序确实有获取用户电子邮件地址的合法需求，如果不测试每个应用程序，就无法确定某个应用程序是否正确使用了该属性。正如我们在自己的测试中指出的，这是一个非常耗时的过程。
MSRC 还表示，他们已经与应用程序供应商进行了沟通，那些未修复其应用程序的供应商可能会被从 Entra 应用程序库中移除。
八、披露与时间线
我们惊讶地发现 nOAuth 攻击仍然有效，尤其是在 Entra 应用程序库中发布的应用程序里，因此我们向 MSRC 提交了一个案例（分配了案例号 93209）。
考虑到 nOAuth 攻击检测的难度，我们也敦促微软身份产品组采取更积极的措施来保护客户。我们建议向服务主体的客户发出警告，提示该应用程序允许未经验证的电子邮件声明，尽管正如我们指出的，这并非存在 nOAuth 漏洞的绝对标识。
我们还向 MSRC 指出了我们发现的九个存在漏洞的应用程序，以备 MSRC 与这些供应商联系。
- • 2024 年 12 月 3 日： 在 MSRC 创建案例
- • 2024 年 12 月 3 日： MSRC 确认收到案例
- • 2024 年 12 月 4 日： 我们向 MSRC 提供了额外的案例详情
- • 2024 年 12 月 17 日： 我们更新了 MSRC 案例，指出我们已与一家供应商合作，修复了一个存在漏洞的应用程序
- • 2025 年 3 月 17 日： 我们向 MSRC 询问案例状态；未收到回复
- • 2025 年 3 月 18 日： 我们在门户中通知 MSRC，计划在 Troopers 2025 会议上披露（如入选）
- • 2025 年 3 月 19 日： 我们通过电子邮件通知 MSRC，计划在 Troopers 会议上披露（如入选），并就披露事宜寻求指导，因为原始漏洞已被披露；未收到回复
- • 2025 年 4 月 18 日： MSRC 关闭了案例，声明“针对您报告的问题已报告修复”，未提供进一步信息
- • 2025 年 4 月至 5 月： 我们进行测试，发现仍有应用程序供应商易受 nOAuth 攻击；我们再次通知了这些供应商，并将我们的发现告知 MSRC
- • 2025 年 6 月： MSRC 提供了关于 Entra 应用程序库中易受 nOAuth 攻击应用程序的详细信息
- • 2025 年 6 月 26 日： 公开披露
注：该文章后续针对跳转至 Microsoft 365 研究存在新的进展，详见同期发布的另一篇文章。
引用链接
[1] 《nOAuth Abuse Alert: Full Account Takeover of Entra Cross-Tenant SaaS Applications》: https://www.semperis.com/blog/noauth-abuse-alert-full-account-takeover/
[2] nOAuth：微软OAuth配置错误如何导致完全账户接管: https://www.descope.com/blog/post/noauth
[3] Azure AD应用程序中潜在的特权提升风险: https://msrc.microsoft.com/blog/2023/06/potential-risk-of-privilege-escalation-in-azure-ad-applications/
[4] 其他地方找到其存档版本: https://web.archive.org/web/20230712111221/https:/learn.microsoft.com/en-us/azure/active-directory/develop/migrate-off-email-claim-authorization
[5] 管理应用授权行为: https://learn.microsoft.com/en-us/graph/applications-authenticationbehaviors?tabs=http&utm_source=cloudseclist.com&utm_medium=referral&utm_campaign=CloudSecList-issue-320#accept-email-addresses-with-unverified-domain-owners-in-claims
[6] 错误的标识符反模式: https://techcommunity.microsoft.com/blog/microsoft-entra-blog/the-false-identifier-anti-pattern/3846013
[7] OpenID Connect 规范第 5.7 节: https://openid.net/specs/openid-connect-core-1_0.html#ClaimStability
[8] ID token 声明参考: https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference#payload-claims
[9] 微软文档表明该声明是可选的: https://learn.microsoft.com/en-us/entra/identity-platform/optional-claims-reference#v10-and-v20-optional-claims-set
交流群
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：云原生安全指北 Dubito《nOAuth攻击剖析：Entra跨租户SaaS应用面临账户完全劫持风险》