Oauth 2.0 Live Connect OAuth2的严重重播攻击问题?为什么授权码允许被多次使用?

Oauth 2.0 Live Connect OAuth2的严重重播攻击问题?为什么授权码允许被多次使用?,oauth-2.0,dotnetopenauth,windows-live-id,liveconnect,live-connect-sdk,Oauth 2.0,Dotnetopenauth,Windows Live Id,Liveconnect,Live Connect Sdk,首先谢谢你抽出时间。我非常关注Live Connect的OAuth2 API 我遵循这一点,并使用DotNetOpenAuth为我们的联邦身份和访问管理系统实现/集成LiveId身份验证/授权 在相当长的一段时间里,一切都运转良好。但是现在我在修复LiveId登录模块的重播攻击问题时遇到了严重的问题。让我们从上面的文章看授权代码授予流程。 *4.用户代理使用重定向URI调用客户端,该URI包括授权代码和客户端提供的任何本地状态。例如:…Callback.htm?code=authorizati

首先谢谢你抽出时间。我非常关注Live Connect的OAuth2 API

我遵循这一点,并使用DotNetOpenAuth为我们的联邦身份和访问管理系统实现/集成LiveId身份验证/授权

在相当长的一段时间里,一切都运转良好。但是现在我在修复LiveId登录模块的重播攻击问题时遇到了严重的问题。让我们从上面的文章看授权代码授予流程。 *4.用户代理使用重定向URI调用客户端,该URI包括授权代码和客户端提供的任何本地状态。例如:…Callback.htm?code=authorization\u code。 5.客户端通过使用其客户端凭据进行身份验证,从授权服务器的令牌终结点请求访问令牌,并包括在上一步中收到的授权代码。客户端包括用于获取授权代码以进行验证的重定向URI。*”

在步骤4之后,Live Connect OAuth2服务器返回到我的回调端点,并带有授权代码和状态,如下所示:

问题是,授权代码可以被多次使用。因此导致了严重的重播攻击问题,如以下场景:

  • 用户A在登录到我的应用程序时,选择LiveId登录,然后他被重定向到LiveId登录页面。然后他登录,Live Connect OAuth2服务器返回到回调端点,代码=xxx&state=yyy…用户A然后使用此授权代码获取访问令牌

  • 用户B在登录到我的应用程序时,选择LiveId登录,然后在LiveId的登录页面登录。实时连接OAuth2服务器现在返回代码=kkk&state=ggg

  • 如果我这次使用Webscarab之类的工具来捕获响应/请求,然后将从OAuth2服务器返回的内容更改为code=xxx&state=ggg(旧的授权代码是给用户A的,而不是用户B的)。然后,使用该重播授权码请求访问令牌的过程顺利进行。你猜怎么着?我再次收到了之前发给用户A的访问令牌…最后,用户B可以作为用户A登录到我的应用程序

    请注意,对Google OAuth2服务器应用如上相同的重播攻击时,我收到了来自服务器的错误请求错误,Google OAuth2授权代码不能被多次使用。Google登录和LiveId登录的代码流或实现完全相同

    我使用DotNetOpenAuth.OAuth2.WebServerClient为Google和LiveId实现OAuth2身份验证流。同样,完全相同的代码,但是当重用授权代码时,GoogleOAuth2服务器返回了“坏请求”,但是LiveId返回了前一个用户的旧访问令牌

    这是一个严重的安全问题。希望你们对此有一些想法。 或者希望我在某些方面是错的。请指出

    提前非常感谢, Phuc Le.

    OAuth 2规范是:

    如果一个授权码被多次使用,授权服务器必须拒绝该请求,并应(在可能的情况下)撤销先前基于该授权码颁发的所有令牌

    这是为您上面提到的客户准备的

    在你的情况下,你应该考虑这个问题

    同时,您可以在客户端实现已使用授权代码的缓存,并检查已发布的代码。请注意,如果提供程序为两个不同的用户随机生成相同的代码,这也可能产生误报(这可能非常不可能,具体取决于实现情况)。

    OAuth 2规范是:

    如果一个授权码被多次使用,授权服务器必须拒绝该请求,并应(在可能的情况下)撤销先前基于该授权码颁发的所有令牌

    这是为您上面提到的客户准备的

    在你的情况下,你应该考虑这个问题


    同时,您可以在客户端实现已使用授权代码的缓存,并检查已发布的代码。请注意,如果提供商为两个不同的用户随机生成相同的代码,这也可能产生误报(这可能不太可能,具体取决于实现情况)。

    感谢Gerlinger的回复,回到问题所在。如链接@5.1.5.4中所述。限制使用次数或一次性使用授权服务器可能会限制使用特定令牌可以执行的请求或操作的数量。此机制可用于缓解以下威胁。。。如上所述,我认为Live Connect OAuth 2.0服务器选择了限制使用次数的方法,而不是“一次性使用”。我会在LiveConnect论坛上再次询问,看看您的解决方案是否使用缓存来存储已使用的授权码,以便稍后检查。事实上,这对我的案子不起作用。想象一下,我们的应用程序运行在许多服务器上,它们彼此之间不共享任何内容,没有中央会话或缓存,数据库……没有共享内容。因此,可能在这个实例/服务器中已经使用过一次授权代码,但在其他实例/服务器中没有。现在黑客用它来重播攻击另一个服务器/实例,实际上没有办法检查。请分享你的想法?非常感谢。@PhucLe按照规范中的规定,不允许多次使用授权代码。威胁模型规范中的这句话针对的是其他容易重放攻击的令牌。我只是发布它来证明限制使用或使用一次性令牌是处理重播攻击的推荐方法。在您的场景中,除了等待,您没有什么可以做的