身份验证绕过：微软 SSO 集成中的顺序用户 ID 漏洞 | 严重漏洞

如果你是渗透测试人员或漏洞赏金猎人，千万不要在测试中跳过 SSO。这是那些人人都认为安全的功能之一，但我不断在其中发现严重缺陷。

我决定撰写本文，是因为我已经不止一次遇到同类漏洞，而且令人惊讶的是它依然存在。人们通常认为，一旦应用程序采用单点登录（特别是像微软这样的方案），身份验证就会自动变得安全。但这种假设是危险的。

在最近一次测试中，我发现登录流程表面看起来完美无缺——微软 SSO、Authenticator 提示，一切就位。但当我深入后端时，整个安全模型就崩溃了。服务器依赖来自客户端的可预测 user_id 来决定哪个账户处于活跃状态。更改该值，你突然就能以他人身份登录。

漏洞原理

该应用使用微软 SSO（Azure AD）进行登录。SSO 完成后，应用会颁发与用户邮箱绑定的令牌。

存在一个接受 userId 的 API 端点，服务器使用它来设置活跃账户。服务器既不验证 userId 是否与令牌中的已认证身份对应，也不验证 MFA 声明。

userId 值为顺序且可枚举 → 攻击者可猜测其他用户的 id 并切换到其账户。

风险分析

• 如果后端从不检查 MFA 声明（amr、auth_time），UI 中的 MFA 就毫无意义。Authenticator 提示的存在并不保证强制执行

• 信任客户端提供的标识符是根本性错误。任何来自客户端的内容都必须根据经过验证的服务端声明进行验证

• 可预测/顺序 ID 极易枚举，使授权检查变成可选的表演

• 账户接管是即时发生的。一旦攻击者能在没有服务端检查的情况下更改活跃用户上下文，整个账户就会被入侵

根本原因

• 后端信任客户端提供的状态：开发者使用来自客户端的 userId 作为会话/账户选择的真相来源，而不是将会话与已验证的令牌声明（sub）绑定

• 令牌绑定逻辑薄弱：应用在 SSO 后颁发令牌，但从未强制执行该令牌与活跃会话之间的严格绑定

• 加密令牌或令牌验证缺失：即使令牌被加密（JWE）或由可信 IdP 返回，团队有时也会跳过服务端的适当解密/验证

• 身份验证与授权混淆：流程将"我有令牌"与"我被允许以该用户身份操作"分离

• 遗留或匆忙的集成：快速 SSO 集成、演示代码或遗留路由经常复制粘贴基于 id 的简单逻辑并暴露给客户端

• 可预测标识符+缺乏速率限制：使用顺序整数作为公共用户 ID 使枚举成本低廉

总结

SSO 是一个集成方案，而非安全保证。如果你的后端哪怕稍微信任客户端输入，IdP 保护就会被绕过。务必验证令牌、在服务器端强制执行 MFA，并停止暴露顺序 ID。更多精彩内容 请关注我的个人公众号 公众号（办公 AI 智能小助手）对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）

公众号二维码

办公AI智能小助手

公众号二维码

网络安全技术点滴分享