【问题标题】:Bodysnatcher "OpenId Provider" attack questionBodysnatcher“OpenId Provider”攻击问题
【发布时间】:2011-01-26 04:12:27
【问题描述】:

好的,基本上这是 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,该网站使用的是 open id,并且 bob 有一个帐户。

  5. 她告诉 www.bcs.com 使用 OpenId 提供程序 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 的站点更改其标识符。我的意思是,如果不尝试保护其成员,为什么还要麻烦这样做?

【问题讨论】:

    标签: openid openid-provider google-openid


    【解决方案1】:

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

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

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

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

    【讨论】:

    • 好的,很高兴知道,因为我们使用的是“DotNetOpenAuth”。
    • 所以回到散列问题是错误的。那么我们可以安全地假设我们收到的 openIds 不必像某种密码一样对待吗?我的意思是,我们并不是在谈论公然公开它,只是如果我们将其视为安全数据,则需要付出一些额外的努力。另外,我明白你对谷歌的意思。正如 StackOverFlow 所发现的那样,它肯定会阻止跨站点跟踪。
    • 别介意!我看到你对别人问题的回答就是这样。
    猜你喜欢
    • 1970-01-01
    • 2011-06-30
    • 1970-01-01
    • 1970-01-01
    • 2012-08-28
    • 2016-09-11
    • 1970-01-01
    • 1970-01-01
    • 2012-09-02
    相关资源
    最近更新 更多