使用 oauth2 客户端凭据防止中间人攻击
Prevent man-in-the-middle attack with oauth2 client credentials
现在我正在开发一个微服务系统，使用 Nginx 作为网关，使用 Keycloak 作为 authorization/authentication。移动应用程序使用 openidconnect 和 grant_type=client_credentials 来获取令牌。
授予类型 'client_credentials' 需要在请求正文中 client_id、client_secret。
如果有人使用 Fiddler 作为中间人进行攻击，他可以知道客户端 id/secret，而不是通过使用它们来获取访问令牌来成为中间人。
那么如何防止这种攻击呢？
我用的是https，但是我知道Fiddler可以解密https。
请帮我。非常感谢。
client_credentials 授权不是本机或其他客户端应用程序（包括单页网络应用程序、移动应用程序等）的正确 oauth 流程。您想要的是实现代码交换 (PKCE) 流程的证明密钥。此流程不需要客户端密码，只需要客户端 ID。可以在 Auth0 的网站上找到有关流程的精彩文章：
打开 ID 连接
A mobile app use openidconnect with grant_type=client_credentials to get tokens.
首先，正如其他人已经指出的那样，这不是在移动应用程序中使用的正确授权类型，您可能希望使用 authorization_code 流程。
阅读 this article 中的更多信息：
We will now go through a minimal example of how to obtain an ID token for a user from an OP, using the authorisation code flow. This is the most commonly used flow by traditional web applications.
提取秘密
Grant type 'client_credentials' need client_id, client_secret in request body.
If someone use Fiddler to attack as man in the middle, he can know client id/secret, than he can be man-in-the-middle by using them to get access token.
考虑到您决定为您的移动应用实施正确的 OpenID Connect 授权流程，因此不再泄露您的 client_secret，攻击者仍然可以使用 Fidller 中间人攻击您的连接并提取结果 Authorization 令牌来验证 API 服务器中移动应用程序的用户，就像我在文章中展示的那样
Steal that Api Key with a Man in the Middle Attack:
In order to help to demonstrate how to steal an API key, I have built and released in Github the Currency Converter Demo app for Android, which uses the same JNI/NDK technique we used in the earlier Android Hide Secrets app to hide the API key.
So, in this article you will learn how to setup and run a MitM attack to intercept https traffic in a mobile device under your control, so that you can steal the API key. Finally, you will see at a high level how MitM attacks can be mitigated.
虽然本文展示了一种窃取 Api 密钥的攻击，但从请求中窃取任何其他机密或数据的原理是相同的。
攻击者还可以借助检测框架在 运行 时挂钩到您的移动应用程序代码中并从中窃取任何秘密，此类工具的一个很好的例子是 Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
可能的解决方案
So how to prevent this case of attack?
在一定程度上防止客户端攻击是可能的，但最终您无法看到攻击者何时能够绕过您在移动应用程序 APK 中提供的安全措施，因为当熟练的攻击者知道如何正确使用检测框架，他会深入研究执行安全决策的代码，并始终确保 return 一切正常。
因此，您想要转移注意力，让您的 API 服务器能够可靠地知道它确实在与您发布的完全相同的 APK 对话，而不是与被篡改和破坏的 APK 对话，或者请求来自机器人。
移动设备认证
自 Android 的 DeviceCheck for iOS and SafetyNet 发布以来，我看到越来越多的开发人员将其作为证明其移动应用程序的一种形式，但有些人未能理解此解决方案的真正含义专为。
就拿Google自己的话来说吧SafetyNet:
- Using the SafetyNet Attestation API results as the only signal to attack abuse
It may be tempting to think that the SafetyNet Attestation API provides all the necessary signals for protecting an app against abusers, and use it as the only signal for building an anti-abuse system.
The SafetyNet Attestation API can only give signals about the state of a device, not the intent of a user, which is what an anti-abuse system should be designed to detect. Therefore, you might want to consider including other signals, such as access logs and behavioral patterns, to more accurately detect abusive users, and consider not blocking users solely on a failed attestation. Furthermore, there are many other conditions that cause an attestation to fail, such as network connection problems, quota issues, and other transient problems.
In other words, not all users who fail attestation are necessarily abusers, and not all abusers will necessarily fail attestation. By blocking users solely on their attestation results, you might be missing abusive users that don't fail attestations. Furthermore, you might also be blocking legitimate, loyal customers who fail attestations for reasons other than abuse.
我在 上扩展了更多关于开发人员必须注意的问题 Android 等同于 ios devicecheck.
所以底线是，在 SafetyNet 的情况下，它证明了移动设备而不是您的移动应用程序，但它仍然是一个很好的安全机制。
要证明移动应用程序确实没有受到危害或滥用，您需要采用移动应用程序证明解决方案。
移动应用认证
移动应用认证的作用是证明您上传的 APK 没有被泄露或尚未被泄露的风险，从而使您的 API 服务器具有高度的可信度，这确实是与您的移动应用程序的真实实例通信。
我邀请您阅读 我给了另一个问题，该问题更详细地解释了这个概念，同时为您提供了更多背景信息，为什么它可能更适合解决您的问题。
因此，如果您将移动应用证明与移动设备证明放在一起，那么您可能已经找到了保护您的移动应用免遭因 OAuth 凭据泄露而被滥用的最佳解决方案。
您想加倍努力吗？
在任何对安全问题的回答中，我总是喜欢引用 OWASP 基金会的出色工作，因此：
对于移动应用程序
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
对于APIS
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
现在我正在开发一个微服务系统，使用 Nginx 作为网关，使用 Keycloak 作为 authorization/authentication。移动应用程序使用 openidconnect 和 grant_type=client_credentials 来获取令牌。
授予类型 'client_credentials' 需要在请求正文中 client_id、client_secret。
如果有人使用 Fiddler 作为中间人进行攻击，他可以知道客户端 id/secret，而不是通过使用它们来获取访问令牌来成为中间人。
那么如何防止这种攻击呢？
我用的是https，但是我知道Fiddler可以解密https。
请帮我。非常感谢。
client_credentials 授权不是本机或其他客户端应用程序（包括单页网络应用程序、移动应用程序等）的正确 oauth 流程。您想要的是实现代码交换 (PKCE) 流程的证明密钥。此流程不需要客户端密码，只需要客户端 ID。可以在 Auth0 的网站上找到有关流程的精彩文章：
打开 ID 连接
A mobile app use openidconnect with grant_type=client_credentials to get tokens.
首先，正如其他人已经指出的那样，这不是在移动应用程序中使用的正确授权类型，您可能希望使用 authorization_code 流程。
阅读 this article 中的更多信息：
We will now go through a minimal example of how to obtain an ID token for a user from an OP, using the authorisation code flow. This is the most commonly used flow by traditional web applications.
提取秘密
Grant type 'client_credentials' need client_id, client_secret in request body. If someone use Fiddler to attack as man in the middle, he can know client id/secret, than he can be man-in-the-middle by using them to get access token.
考虑到您决定为您的移动应用实施正确的 OpenID Connect 授权流程，因此不再泄露您的 client_secret，攻击者仍然可以使用 Fidller 中间人攻击您的连接并提取结果 Authorization 令牌来验证 API 服务器中移动应用程序的用户，就像我在文章中展示的那样
Steal that Api Key with a Man in the Middle Attack:
In order to help to demonstrate how to steal an API key, I have built and released in Github the Currency Converter Demo app for Android, which uses the same JNI/NDK technique we used in the earlier Android Hide Secrets app to hide the API key.
So, in this article you will learn how to setup and run a MitM attack to intercept https traffic in a mobile device under your control, so that you can steal the API key. Finally, you will see at a high level how MitM attacks can be mitigated.
虽然本文展示了一种窃取 Api 密钥的攻击，但从请求中窃取任何其他机密或数据的原理是相同的。
攻击者还可以借助检测框架在 运行 时挂钩到您的移动应用程序代码中并从中窃取任何秘密，此类工具的一个很好的例子是 Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
可能的解决方案
So how to prevent this case of attack?
在一定程度上防止客户端攻击是可能的，但最终您无法看到攻击者何时能够绕过您在移动应用程序 APK 中提供的安全措施，因为当熟练的攻击者知道如何正确使用检测框架，他会深入研究执行安全决策的代码，并始终确保 return 一切正常。
因此，您想要转移注意力，让您的 API 服务器能够可靠地知道它确实在与您发布的完全相同的 APK 对话，而不是与被篡改和破坏的 APK 对话，或者请求来自机器人。
移动设备认证
自 Android 的 DeviceCheck for iOS and SafetyNet 发布以来，我看到越来越多的开发人员将其作为证明其移动应用程序的一种形式，但有些人未能理解此解决方案的真正含义专为。
就拿Google自己的话来说吧SafetyNet:
- Using the SafetyNet Attestation API results as the only signal to attack abuse
It may be tempting to think that the SafetyNet Attestation API provides all the necessary signals for protecting an app against abusers, and use it as the only signal for building an anti-abuse system.
The SafetyNet Attestation API can only give signals about the state of a device, not the intent of a user, which is what an anti-abuse system should be designed to detect. Therefore, you might want to consider including other signals, such as access logs and behavioral patterns, to more accurately detect abusive users, and consider not blocking users solely on a failed attestation. Furthermore, there are many other conditions that cause an attestation to fail, such as network connection problems, quota issues, and other transient problems.
In other words, not all users who fail attestation are necessarily abusers, and not all abusers will necessarily fail attestation. By blocking users solely on their attestation results, you might be missing abusive users that don't fail attestations. Furthermore, you might also be blocking legitimate, loyal customers who fail attestations for reasons other than abuse.
我在
所以底线是，在 SafetyNet 的情况下，它证明了移动设备而不是您的移动应用程序，但它仍然是一个很好的安全机制。
要证明移动应用程序确实没有受到危害或滥用，您需要采用移动应用程序证明解决方案。
移动应用认证
移动应用认证的作用是证明您上传的 APK 没有被泄露或尚未被泄露的风险，从而使您的 API 服务器具有高度的可信度，这确实是与您的移动应用程序的真实实例通信。
我邀请您阅读
因此，如果您将移动应用证明与移动设备证明放在一起，那么您可能已经找到了保护您的移动应用免遭因 OAuth 凭据泄露而被滥用的最佳解决方案。
您想加倍努力吗？
在任何对安全问题的回答中，我总是喜欢引用 OWASP 基金会的出色工作，因此：
对于移动应用程序
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
对于APIS
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.