我知道有很多类似的问题，但我很困惑。
我的目的是仅从我的应用程序访问我的 API。
1）我学过JWT，但我有一个疑问。任何人都使用我的 API 登录来访问我的应用程序。获取令牌并向服务器发送请求。对吧？
0Auth 不适合我，因为我不使用第三方应用程序。
我的想法是在客户端的服务器上生成一个密钥和一个。然后我使用客户端密钥加密我发送的参数（按特定顺序）。最后在服务器上我解密并进行比较（因为我知道参数的顺序）。
但是可以通过逆向发现客户端上的key
你有什么建议？
【问题讨论】：
标签： android api security jwt jwt-auth
我的目的是仅从我的应用程序访问我的 API。
让我们首先澄清开发人员之间的一个常见误解，即 WHO 与 WHAT 正在访问 API 服务器。
为了更好地了解 WHO 与 WHAT 访问您的 API 服务器之间的区别，我建议您阅读我的文章中的 this section，但我会提取这里有几行：
谁是移动应用的用户，我们可以通过多种方式进行身份验证、授权和识别，例如使用 OpenID Connect 或 OAUTH2 流。
what 是向 API 服务器发出请求的事物。它真的是您的移动应用程序的真实实例，还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动在您的 API 服务器周围探查？
因此，重要的是，您的移动应用程序的用户是 WHO，而不是 WHAT 正在访问您的 API 服务器。
OAuth 不适合我，因为我不使用第三方应用程序。
您无需使用第三方应用程序即可使用 OAuth 进行身份验证和授权 WHO 正在访问您的 API 服务器，相反我会建议您使用它。
1) 我学过 JWT，但我有一个疑问。任何人都使用我的 API 登录来访问我的应用程序。获取令牌并向服务器发送请求。对吧？
是的，任何人（WHO 和 WHAT）获取您的 JWT 令牌，或者就此而言，您为保护对 API 的访问而实施的任何其他类型的秘密，将能够使用它来伪装成该秘密对您的 API 服务器所代表的任何内容。
我的想法是在客户端的服务器上生成一个密钥和一个。然后我使用客户端密钥加密我发送的参数（按特定顺序）。最后在服务器上我解密并进行比较（因为我知道参数的顺序）。 但是可以通过反向发现客户端上的密钥
是的，可以通过移动应用的逆向工程发现。
可以使用移动安全框架等工具通过静态二进制分析完成，也可以在运行时使用 Frida 或 Xposed。
Mobile Security Framework Mobile Security Framework 是一个自动化的一体化移动应用程序 (Android/iOS/Windows) 渗透测试框架，能够执行静态分析、动态分析、恶意软件分析和 Web API 测试。
将您自己的脚本注入黑盒进程。挂钩任何功能、监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，立即查看结果。所有这些都无需编译步骤或程序重新启动。
Xposed 是一个模块框架，可以在不触及任何 APK 的情况下改变系统和应用的行为。这很棒，因为这意味着模块可以在不同版本甚至 ROM 上工作而无需任何更改（只要原始代码没有太大更改）。它也很容易撤消。
如果您还不熟悉如何通过逆向工程从移动应用 APK 中提取秘密，那么您可以阅读文章 How to Extract an API Key from a Mobile App with Static Binary Analysis 以更好地掌握其中一种方法。
静态二进制分析很难掌握使用JNI/NDK工具集提取隐藏在C原生代码中的秘密，因此在运行时挂钩Frida或xPosed提取秘密会更容易.攻击者会在返回密钥（在您的情况下为加密密钥）的方法中挂钩您的代码，即使它是从 Android 共享首选项中检索到的。
使用 Android Studio 2.2 及更高版本，您可以使用 NDK 将 C 和 C++ 代码编译为本机库，然后使用 IDE 的集成构建系统 Gradle 将其打包到您的 APK 中。然后，您的 Java 代码可以通过 Java 本机接口 (JNI) 框架调用本机库中的函数。
SharedPreferences 对象指向一个包含键值对的文件，并提供简单的方法来读取和写入它们。每个 SharedPreferences 文件都由框架管理，可以是私有的，也可以是共享的。
您可以访问这个 Github 存储库android-hide-secrets，查看一个基本的 Android 移动应用程序，该应用程序向您展示了几种隐藏秘密的方法，包括 JNI/NDK 方法：
一个快速演示，展示了在移动应用中隐藏秘密的几种方法，例如：
- 源代码
- 清单文件
- gradle 文件
- JNI/NDK
总而言之，您的想法是有价值的，但您需要了解它只会让人难以绕过，而不是不可能。那么你应该使用它吗？是的，在我看来，我们应该通过应用尽可能多的层来争取深度防御，因为这会使攻击者的生活更加艰难，甚至可能会阻止一些攻击的继续进行。
您可以先采取基本的 API 安全措施，然后再采取一些更高级的措施，如果您的 API 保护的数据值得，您甚至可以使用自己的移动应用证明解决方案。
既然您了解了 谁 与 什么 访问您的 API 服务器之间的区别，您可能需要阅读 my article 以了解保护 API 的基本技术：
在本文中，我们将探讨用于保护 API 的最常用技术，包括使用 HTTPS 保护移动应用程序和 API 之间的通信通道的重要性，如何使用 API 密钥来识别每个应用程序上的移动应用程序API 请求，用户代理、验证码和 IP 地址如何用于 bot 缓解，以及最终用户身份验证对移动安全和 API 安全的重要性。我们将讨论这些技术中的每一种，并讨论它们如何影响业务风险状况，即它们是多么容易绕过。
您可以先阅读Mobile API Security Techniques 上的这一系列文章，了解如何使用 API 密钥、HMAC、OAUTH 和certificate pinning 来增强安全性以及如何滥用/破坏它们。
之后，根据您的预算和资源，您可以采用一系列不同的方法和技术来保护您的 API 服务器，我将开始列举一些最常用的方法。
您可以从reCaptcha V3 开始，然后是Web Application Firewall(WAF)，如果您负担得起，最后是User Behavior Analytics(UBA) 解决方案。
谷歌reCAPTCHA V3：
reCAPTCHA 是一项免费服务，可保护您的网站免受垃圾邮件和滥用。 reCAPTCHA 使用高级风险分析引擎和自适应挑战来防止自动化软件参与您网站上的滥用活动。它在让您的有效用户轻松通过的同时做到这一点。
...帮助您检测网站上的滥用流量，而不会产生任何用户摩擦。它会根据与您的网站的互动返回一个分数，并让您更灵活地采取适当的行动。
WAF - Web Application Firewall:
Web 应用程序防火墙（或 WAF）过滤、监控和阻止进出 Web 应用程序的 HTTP 流量。 WAF 与常规防火墙的区别在于，WAF 能够过滤特定 Web 应用程序的内容，而常规防火墙充当服务器之间的安全门。通过检查 HTTP 流量，它可以防止源自 Web 应用程序安全漏洞的攻击，例如 SQL 注入、跨站点脚本 (XSS)、文件包含和安全错误配置。
UBA - User Behavior Analytics:
Gartner 定义的用户行为分析 (UBA) 是一个关于检测内部威胁、针对性攻击和金融欺诈的网络安全流程。 UBA 解决方案着眼于人类行为模式，然后应用算法和统计分析从这些模式中检测出有意义的异常——表明潜在威胁的异常。 UBA 不是跟踪设备或安全事件，而是跟踪系统的用户。 Apache Hadoop 等大数据平台通过分析 PB 级数据以检测内部威胁和高级持续性威胁，正在增加 UBA 功能。
所有这些解决方案都基于否定识别模型，换句话说，它们会尽力通过识别什么是坏的而不是什么来区分好与坏，因此它们很容易出现误报，尽管其中一些人使用的先进技术，例如机器学习和人工智能。
因此，您可能会发现自己经常不得不放松阻止对 API 服务器的访问的方式，以免影响好用户。这也意味着此解决方案需要持续监控，以验证误报不会阻止您的合法用户，同时它们是否正确阻止了未经授权的用户。
关于服务于移动应用的 API，可以通过实施移动应用证明解决方案来使用积极的识别模型，该解决方案在向 API 服务器发出任何请求之前证明您的移动应用及其运行的设备的完整性。
最后，如果你有足够的资源，你可以更进一步，通过构建自己的Mobile APP Attestation 解决方案：
移动应用证明服务的作用是对发送请求的内容进行身份验证，因此只响应来自真正的移动应用实例的请求并拒绝来自未经授权的来源的所有其他请求。
为了了解向 API 服务器发送请求的内容，移动应用证明服务将在运行时以高可信度识别您的移动应用存在、未被篡改/重新打包、未运行在有根设备中，没有被仪器框架（Frida、xPosed、Cydia 等）挂钩，也不是中间人攻击（MitM）的对象。这是通过在后台运行 SDK 来实现的，该 SDK 将与在云中运行的服务进行通信，以证明移动应用程序和运行它的设备的完整性。
成功证明移动应用程序的完整性后，将颁发一个短期 JWT 令牌，并使用只有 API 服务器和云中的移动应用程序证明服务知道的秘密进行签名。在证明失败的情况下，JWT 令牌使用不正确的密钥进行签名。由于移动应用程序不知道移动应用程序证明服务使用的秘密，因此即使应用程序已被篡改、在根设备中运行或通过连接进行通信，也无法在运行时对其进行逆向工程这是 MitM 攻击的目标。
移动应用必须在每个 API 请求的标头中发送 JWT 令牌。这允许 API 服务器仅在可以验证 JWT 令牌已使用共享密钥签名并且尚未过期时才提供请求。所有其他请求将被拒绝。换句话说，有效的 JWT 令牌会告诉 API 服务器发出请求的是上传到 Google 或 Apple 商店的真正移动应用程序，而无效或丢失的 JWT 令牌意味着发出请求的东西未被授权这样做，因为它可能是机器人、重新打包的应用程序或进行中间人攻击的攻击者。
使用移动应用程序证明服务的一大好处是其主动和积极的身份验证模型，它不会产生误报，因此不会阻止合法用户，同时阻止坏人。
在我看来，最好的解决方案是深度防御，通过应用尽可能多的层，这样您就可以增加绕过所有安全层所需的时间、精力和技能组合，从而远离脚本孩子和偶尔的黑客滥用您的服务。
我强烈推荐你，也看看OWASP Mobile Security Project - Top 10 risks
OWASP 移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。
愉快的编码，并保持安全；）
【讨论】：