使用 oauth2 客户端凭据防止中间人攻击答案

【问题标题】：Prevent man-in-the-middle attack with oauth2 client credentials使用 oauth2 客户端凭据防止中间人攻击
【发布时间】：2020-09-13 03:48:47
【问题描述】：

现在我正在开发一个使用 Nginx 作为网关和 Keycloak 作为授权/身份验证的微服务系统。移动应用程序使用 openidconnect 和 grant_type=client_credentials 来获取令牌。
授予类型“client_credentials”在请求正文中需要 client_id、client_secret。
如果有人使用 Fiddler 作为中间人进行攻击，他可以知道客户端 ID/秘密，而不是通过使用它们获取访问令牌来成为中间人。
那么如何防范这种攻击情况呢？

我正在使用 https，但我知道 Fiddler 可以解密 https。
请帮我。非常感谢。

【问题讨论】：

客户端凭据授予不适用于移动应用。您无法对客户端（应用程序）进行身份验证，您只能对用户进行身份验证。你可能想看看Attestation API，虽然这不是你想要的，但可能是相似的或有用的。
没错。客户端凭据授予用于服务到服务的通信。
正如@david-t 所述，您应该使用grant_type=authorization_code 和PKCE。我应该补充一点，证书固定也是完成安全性所必需的。更多信息在这里：Building an OpenID Connect flow for mobile

标签： security oauth-2.0 microservices keycloak man-in-the-middle

【解决方案1】：

开放式连接

移动应用使用 openidconnect 和 grant_type=client_credentials 来获取令牌。

首先，正如其他人已经指出的那样，这不是在移动应用中使用的正确授权类型，相反，您可能希望使用authorization_code 流程。

在this article了解更多信息：

我们现在将通过一个最小的示例来说明如何使用authorisation code flow 从 OP 获取用户的 ID 令牌。这是传统 Web 应用程序最常用的流程。

提取秘密

授权类型“client_credentials”在请求正文中需要 client_id、client_secret。如果有人使用 Fiddler 作为中间人进行攻击，他可以知道客户端 ID/秘密，而不是通过使用它们获取访问令牌来成为中间人。

考虑到您决定为您的移动应用程序实施正确的 OpenID Connect 授权流程，从而不再泄露您的 client_secret，攻击者仍然可以使用 Fidller 中间人攻击您的连接并提取生成的 Authorization 令牌到在 API 服务器中验证移动应用程序的用户，就像我在文章中展示的那样 Steal that Api Key with a Man in the Middle Attack:

为了帮助演示如何窃取 API 密钥，我在 Github 上构建并发布了适用于 Android 的 Currency Converter Demo 应用程序，它使用了与我们在之前的 Android Hide Secrets 应用程序中使用相同的 JNI/NDK 技术来@ 987654327@.

因此，在本文中，您将学习如何设置和运行中间人攻击，以拦截您控制的移动设备中的 https 流量，从而窃取 API 密钥。最后，您将了解如何缓解中间人攻击。

虽然本文展示了窃取 Api Key 的攻击，但从请求中窃取任何其他机密或数据的原理是相同的。

攻击者还可以借助检测框架在运行时挂钩到您的移动应用程序的代码并从中窃取任何秘密，此类工具的一个很好的例子是Frida：

将您自己的脚本注入黑盒进程。挂钩任何功能、监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，立即查看结果。所有这些都无需编译步骤或程序重新启动。

可能的解决方案

那么如何防范这种攻击呢？

在一定程度上防止客户端中的攻击是可能的，但最终您无法看到攻击者何时能够绕过您在移动应用的 APK 中提供的安全措施，因为当熟练的攻击者知道时如何正确使用检测框架，他将深入研究执行安全决策的代码，并使其始终返回一切正常。

因此，您希望将注意力转移到让您的 API 服务器能够可靠地知道它确实在与您发布的完全相同的 APK 进行通信，而不是与被篡改和受损的 APK 通信，或者请求来自机器人.

移动设备认证

自从发布适用于 iOS 的 DeviceCheck 和适用于 Android 的 SafetyNet 以来，我看到越来越多的开发人员将它们作为一种证明他们的移动应用程序的形式，但有些人无法理解这个解决方案的真正目的是什么.

让我们用谷歌自己的话来说SafetyNet：

使用 SafetyNet Attestation API 结果作为攻击滥用行为的唯一信号

人们可能会认为 SafetyNet Attestation API 提供了保护应用免受滥用者侵害的所有必要信号，并将其用作构建反滥用系统的唯一信号。

SafetyNet Attestation API 只能提供有关设备状态的信号，而不是用户的意图，而这正是反滥用系统的设计目标。因此，您可能需要考虑包含其他信号，例如访问日志和行为模式，以更准确地检测滥用用户，并考虑不要仅在认证失败时阻止用户。此外，还有许多其他情况会导致证明失败，例如网络连接问题、配额问题和其他暂时性问题。

换言之，并非所有未通过认证的用户都一定是滥用者，也并非所有滥用者都必然未通过认证。通过仅根据用户的证明结果阻止用户，您可能会错过未通过证明的滥用用户。此外，您还可能会阻止合法、忠诚的客户，这些客户因滥用以外的原因未能通过证明。

我在this answer 上将更多关于开发人员必须了解的内容扩展到问题Android 等效于 ios devicecheck。

所以底线是，在 SafetyNet 的情况下，它证明的是移动设备而不是您的移动应用，但它仍然是一个很好的安全机制。

要证明移动应用确实没有受到损害或滥用，您需要采用移动应用证明解决方案。