4

对于已安装应用程序（例如桌面应用程序/cli/客户端库）的 OAuth 2.0 PKCE 流程，似乎没有什么可以阻止攻击者：

  1. 使用原app获取client_id（client_id是公开的，可以方便地从浏览器栏/源代码中复制）
  2. 制作一个模仿原始应用程序的假应用程序
  3. 使用伪造的应用程序诱使用户授予访问权限，从而获得刷新令牌，这实质上意味着在请求的范围内具有完全访问权限

如果没有 PKCE，就很难伪造应用程序并获取刷新令牌，因为这需要攻击者获取client_secret. 在我看来，虽然 PKCE 提供了对隐式流的安全改进，但它使得伪装使用 OAuth 2.0 的真实应用程序变得更加容易？

我正在使用 googlecloudsdk (gcloud)，它似乎将client_id（甚至许多client_id/client_secret 对）硬编码到分发给客户端的源代码中。我怀疑有什么可以阻止攻击者伪造 gcloud 从而获得对用户 GCP 环境的访问权限（为了证明，运行gcloud auth login它会在控制台中向您显示攻击者需要的 url。）任何人都可以澄清/帮助我了解发生了什么?

4

2 回答 2

2

私有 URI 方案可能是您在桌面上可以做到的最好的方案，但并不像您所说的那样完美。这是我用于我的Desktop Code Sample的，但理想情况下我也想解决上述问题。

对于移动设备，您可以使用声明的 HTTPS 方案来解决问题 - 请参阅我添加到发送的 sllopis 帖子中的答案。

我会知道本机应用程序的更新 OAuth 2.1 指南- 请参阅第 10 节 - 但我认为您不能完全解决这个问题。

预计最终用户会小心他们安装的桌面应用程序，以降低这种情况的风险。希望操作系统支持将在未来提供更好的加密选项。

于 2020-10-23T12:59:26.883 回答
1

只是想跟进这个问题，因为我自己也有同样的问题，但我自己也回答了，我想补充一些这里没有说的东西：

在 oauth2 服务器上设置应用程序时，需要设置多个redirect_uris，授权完成后允许返回的地方。这意味着像您描述的那样创建网络钓鱼攻击的人在登录后无法返回自己的应用程序，并且永远不会收到代码。

有一个单独的攻击，您尝试从非法应用程序返回到合法应用程序，但是这可以通过包含状态变量来解决。

于 2021-08-31T14:19:45.537 回答