0

好的，基本上这里是 Bodysnatcher OpenId Provider 攻击场景。

  1. Bob 的 Google 声明标识符如下，ttps://www.google.com/accounts/o8/id?id=AAtawkQvytyBNNuHpRhn36f8MLvFiJvZg8teNE

  2. Jane 知道如何找到 Bob 的“当前”声明标识符。

  3. 她离开并在这里创建了自己的 OpenId 提供程序 www.jane.com/accounts/o8/id，这样当被询问时它将返回 Bob 声称的标识符。

  4. 她访问了一个编码错误的网站 www.bcs.com，该网站使用开放 ID，而 bob 有一个帐户。

  5. 她告诉 www.bcs.com 使用 OpenId Provider www.jane.com/accounts/o8/id。

  6. 现在这是我不知道的部分，并且想知道它是否可能/现实...... www.jane.com/id 一些如何让 www.bcs.com 相信声称的标识符“字符串”（即站点最终将看到的值）是 ttps://www.google.com/accounts/o8/id?id=AAtawkQvytyBNNuHpRhn36f8MLvFiJvZg8teNE。

即使主机是www.jane.com，是否有可能？

我们正在努力实施 OpenId，我们不想成为那个“编码错误的网站”。我们正在使用一些第三方 .NET 库，它为我们提供声明的标识符，因此我们不确定它在哪里或如何构建它。如果它可能是伪造的，那么我们正在考虑进行一些检查，以确保提供者 OpenId 的 url 与声明标识符中的内容匹配。

这也引发了我们是否应该采取额外步骤对我们声明的标识符进行散列/加扰的担忧。我们认为是这样，因为 Google 会根据请求 OpenId 的站点更改其标识符。我的意思是，如果不尝试保护其成员，为什么还要麻烦这样做呢？

4

1 回答 1

0

您实质上是在询问是否可以编写一个违反规范足以引入安全漏洞的 OpenID 消费者实现。是的。您可以省略整个验证过程并相信用户告诉您的所有内容。

但是对于一个严格遵循 OpenID 规范的消费者来说，这样的攻击是不可能的。

既然您说您使用 .NET 库，您可能会使用 DotNetOpenAuth。它与 stackoverflow 使用的库相同，使用它时您可能不必担心任何漏洞。如果您使用其他库，切换到 DotNetOpenAuth 可能是最佳选择。

至于谷歌返回基于领域的标识符的原因：这样做是为了保护用户的隐私，而不是为了提高安全性。基本上，这可以确保您无法将用户的帐户链接到他的 Google 帐户。

于 2011-01-27T16:51:00.250 回答