【问题标题】:What are the security flaws of exposing OAuth access_token to a user?将 OAuth access_token 暴露给用户有哪些安全漏洞?
【发布时间】:2014-08-15 20:12:44
【问题描述】:

标题可能听起来很愚蠢,但我找不到更好的方式来表达自己。

我有一个使用 OAuth2 服务器的 API。此 API 是我的移动应用程序的后端服务,但我也会将其提供给第三方应用程序。

我还有一个登录方法,用于使用电子邮件和密码对用户进行身份验证,并将 access_token 返回给我的移动应用程序的该用户。

因此,每当您使用emailpassword 创建POST /api/v1/users/auth 时,您将获得一个“完全访问”令牌,它具有所有可用范围。我不认为这里有很大的缺陷,因为任何持有用户凭据的人都可以通过 Web 界面访问应用程序并为所欲为。

但是,认为任何人都可以从现有应用程序获取 access_token 仍然很奇怪,因为在正常的 OAuth 过程中,只有正确的应用程序才能从服务器获取 access_token。但我什至不认为 Oauth2 是为面向客户端的应用程序设计的,例如桌面、javascript 等。

有没有更好的方法来做到这一点?我做错了吗?

谢谢!

【问题讨论】:

    标签: api security oauth


    【解决方案1】:

    只要您通过 https 进行通信并且您的 javascript 是安全/稳定的,您就不必担心。

    否则您将面临以下风险:

    1) 凭据被通过 XSS 漏洞注入您的页面的代码窃取。

    2) 具有读取数据包能力的窃听者可以窃取凭据。

    3) 诸如“FaceNiff”之类的软件可以嗅探 facebook 和 google 等安全令牌,并允许他们使用连接到该 WIFI 的任何用户帐户登录。

    4) 向可能有意滥用这些特权的代码授予特权,或者通过代表更多恶意代码采取行动。

    基本上在通过非安全线路时,您必须记住,授予访问令牌意味着给定用户有权在 Facebook、Github、Google、您的平台等上执行操作 A、B 和 C . 任何获得该令牌的人现在都拥有与相关用户在 Facebook、Github、Google、您的平台等上执行操作 A、B 和 C 的相同权利。

    article 提供了对 OAuth 令牌背后概念的透彻理解。

    如果您有任何问题,请告诉我!

    【讨论】:

    • 太棒了!我已经在使用 https,因为 Oauth2 不像 Oauth1 那样提供加密。谢谢! (顺便说一句,文章很棒)
    猜你喜欢
    • 2011-03-12
    • 1970-01-01
    • 1970-01-01
    • 2011-08-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-02-02
    • 2015-10-07
    相关资源
    最近更新 更多