假设您有一个使用 OAuth 的应用程序，因此该应用程序可以登录到用户的服务（例如 OneDrive、Google Drive 等）
在应用程序中，您已将 OAuth 客户端密码（和客户端 ID）作为字符串常量包含在内。
攻击者使用逆向工程技术从您的应用程序中提取这些信息。知道您的应用程序的 OAuth 客户端密码后，攻击者现在可以做的最糟糕的事情是什么？
如果您的 OAuth 客户端密码泄露，最糟糕的情况是什么？
信息安全
oauth
秘密分享
2021-08-16 16:58:07
3个回答
有时您必须共享 OAuth 客户端密码，移动应用程序就是这种情况。这里真正的保护是可以使用 OAuth 机密的白名单。尽管共享 OAuth 客户端机密的名称“机密”对于移动应用程序来说通常不是问题 - 并且是运行所必需的。
在 2-legged 或 3-legged OAuth 身份验证流中使用的共享密钥可能允许攻击者启动 SSO 流并解开加密的 OAuth 令牌。这可能是也可能不是问题，通常这些令牌具有 SSO 流终止位置的严格白名单，并且终止是重要的部分，因为这是发送访问令牌的地方。攻击者可能能够使用另一个漏洞，例如开放重定向来破坏 SSO 流，这本身就是 OAuth RFC 违规。这两个问题的结合将导致帐户接管链式利用。
尽量避免分享秘密，并确保其他保护措施到位。考虑阅读 OAuth 安全最佳实践 IETF 文档，了解 OAuth 可能出错的所有方式。
在授权代码授权类型中，客户端机密应该保密，用户可以告诉服务您的应用程序有权访问其帐户的某些元素。这里重要的是他们已经授权了您的应用程序，而不是任何其他应用程序。客户端密钥是您如何向服务验证您的应用程序。
获取客户端机密可能会允许恶意应用程序冒充您的应用程序，以及已授予它的任何授权。这可能包括重放访问和刷新令牌，以便在未经用户许可的情况下访问用户的帐户。
我确实相信攻击者通常需要获取额外的信息（例如访问令牌）才能使客户端机密在实践中有用（我很乐意听到任何情况并非如此的情况）。在某些情况下，现有用户被引诱到恶意页面（访问客户端密码）的攻击可能会奏效——尽管引荐来源和用户返回的页面可能会出现复杂情况。
严重程度（“它可以做的最坏情况”）会因范围而异，但它可能会对应用程序的用户产生负面影响。在您的 Google Drive 和 OneDrive 示例中，它可能允许攻击者读取或修改用户的文件，例如，如果这是他们给予的授权。
参考：
- https://salesforce.stackexchange.com/questions/14009/whats-the-benefit-of-the-client-secret-in-oauth2
- https://www.rfc-editor.org/rfc/rfc6819#section-4.1.1
隐式授权类型最适合令牌无法保密的环境（本机桌面、本机移动设备、客户端浏览器等）。
您提供给“客户端 ID/秘密”的 API 配额可能会被随机的第 3 方应用程序窃取。如果您使用付费 API，这可能会出现问题。
如果攻击者获得了“客户端 ID/秘密”和最终用户的“访问令牌”，那么攻击者实际上可以窃取或破坏最终用户的数据。所以，有点像施虐者现在有了你的身份证。他们需要密码才能对最终用户做最坏的事情。