为啥在 Azure AD B2C 中重定向 URL 是完全限定的？

Posted 2023-02-19

【中文标题】为啥在 Azure AD B2C 中重定向 URL 是完全限定的？

【英文标题】：Why is Redirect URL Fully Qualified in Azure AD B2C?为什么在 Azure AD B2C 中重定向 URL 是完全限定的？

【发布时间】：2018-05-11 06:18:08

【问题描述】：

为什么redirect URL 必须完全匹配？域级别的匹配不足以保证适当的安全性吗？

如果我有数百条路径怎么办？

示例网址：

https://myawesomesite.com https://myawesomesite.com/account/profile https://myawesomesite.com/games/fungame/points https://www.myawesomesite.com/games/fungame/points

...

我必须将上述 4 个重定向 URL 输入到我的 B2C 应用配置中。

【问题讨论】：

您的出色应用是否在同一端点处理所有身份验证响应（例如 /oidc-signin）？

没有。想象一下，我有 100 条独特的路径，其中 99 条经过了身份验证。用户可以为 99 条路径中的任何一条添加书签。

@ChrisPadgett 如果他们点击经过身份验证的页面，它应该重定向到 B2C 并返回该页面。

Follow up related question

【参考方案1】：

这实际上在RFC 6819“OAuth 2.0 威胁模型和安全注意事项”部分4.1.5、4.2.4 和5.2.3.5 中进行了讨论。

4.1.5。威胁：在客户端打开重定向器

一个开放的重定向器是一个端点使用一个参数来自动 将用户代理重定向到参数值指定的位置 没有任何验证。如果授权服务器允许客户端 要只注册重定向 URI 的一部分，攻击者可以使用开放的 客户端操作的重定向器构造一个重定向URI 将通过授权服务器验证，但将发送 对受控端点的授权“代码”或访问令牌 攻击者。

影响：攻击者可以访问授权“代码”或访问令牌。

对策：

o 要求客户端注册完整的重定向 URI (Section 5.2.3.5)。"

Section 5.2.3.5 讨论了这可能过于严格的情况并用于替代解决方案。

通常，state 参数也可用于按照 Chris 的建议进行确定性重定向。但是，您必须确保这样的解决方案最终也不会成为开放式重定向器，因此 state 参数要么需要受到保护（例如加密/签名），要么与 cookie 一起使用。

【讨论】：

如果我拥有域 myawesomesite.com，并且我有一个开放的重定向器，它允许该域上的任何重定向 URL，那么攻击者怎么能使用重定向 uri 进行猴子呢？它仍然需要重定向到我的域。

一个常见的情况是redirect_url接受一些查询参数，攻击者可以利用这些参数重定向到他们的站点。威胁模型假设用户代理被重定向“没有任何验证”。您的建议是某种约束或验证。 Azure AD 尝试使用适用于大多数情况的方法取得平衡，但仍限制通配符和查询参数。 （请注意，这些漏洞今天仍然存在，尤其是在复杂的应用程序中：google.com/…）

感谢您编辑我的回复 spotmahn。昨晚只有手机版，好像没有全功能的编辑器。

啊，“查询参数”，好点！感谢您的详细回复！

关于using the state parameter的后续问题

【参考方案2】：

所有身份验证请求都包含两个重定向 URL，这很常见（也是最简单的）：

在“redirect_uri”参数中传递的一个（通常称为回复 URL），必须向 Azure AD B2C 注册，所有的身份验证响应都从 Azure AD B2C 返回到依赖方应用程序。 https://www.myawesomesite.com/oidc-signin 就是一个例子。 另一个（通常称为返回 URL）在“状态”参数中往返，不必在 Azure AD B2C 中注册，在依赖方应用程序处理完身份验证响应后，最终用户返回给它。 https://www.myawesomesite.com/games/fungame/points 就是一个例子。

身份验证处理程序（例如 the ASP.NET Core authentication middleware）为您管理这些重定向 URL。

例如，当身份验证处理程序创建身份验证请求时，它会在“状态”请求参数中对当前受保护的 URL（例如 https://www.myawesomesite.com/games/fungame/points）进行编码。

为确保此 URL 不被篡改，应使用加密或签名保护“状态”参数。

当身份验证处理程序处理身份验证响应时，假设它是一个成功的响应，它会创建一个身份 cookie 并将最终用户从 https://www.myawesomesite.com/oidc-signin 重定向到“状态”响应参数中最初受保护的 URL。

【讨论】：

如果“状态”将用户发送到另一个域（例如，另一个地理区域中的相同应用程序），则该过程重复（IP 重定向回该地理实例的 /oidc-signin）但用户这样做不必再次提供凭据 (SSO)，但必须等待交互完成。据我了解...