我的Android应用具有excel导出和导入功能，最近我想通过添加写保护密钥来确保此功能的安全。最初，我将硬编码的密钥放在源代码中，但是显然由于逆向工程，这根本不安全。 我读了很多书，我认为我的解决方案现在是安全的，但是我不确定。您能否看一下并指出可能的警告？
只有用提供的密码导出的Excel工作表可以再次导入。
我还具有PDF导出功能。 PDF应由应用签名。该过程与之前相同，但使用的pkcs密钥包含私钥和公钥作为base64字符串。
植根设备怎么样，攻击者能否获得发送的密码/ pkcs密钥？
答案 0 :(得分：1)
我读了很多书，我认为我的解决方案现在是安全的，但是我不确定。您可以看看并指出可能的警告吗？
乍一看：
- 以JSON格式发送回应用程序帐户信息和excel导出密码（HTTPS POST）
该过程与以前相同，但使用包含私有和公共密钥作为base64字符串的pkcs密钥。
私有密钥可以保持私有的唯一方法是将其安全地存储在要使用的位置，我强烈建议在与使用位置相同的位置生成它。同一台服务器。
从私钥离开后端服务器的那一刻起，它就不再安全地存储了，现在任何有技能和知识的人都可以使用它来使用大量的开源和付费工具进行逆向工程静态二进制文件，甚至在运行时进行自检，并更改其行为或提取数据，也就是您的私钥。
对于静态二进制分析，我们有一个开放源代码工具MobSF，该工具在幕后结合了其他几个开放源代码工具，这些工具可以反编译，分析和提取静态二进制数据。
MobSF
移动安全框架（MobSF）是一种自动化的多合一移动应用程序（Android / iOS / Windows）可以进行静态和动态分析的笔测，恶意软件分析和安全评估框架。 MobSF支持移动应用程序二进制文件（APK，IPA和APPX）以及压缩的源代码，并提供REST API以与CI / CD或DevSecOps管道无缝集成。动态分析器可帮助您执行运行时安全性评估和交互式检测。 >
关于运行时，可以使用Frida或xPosed钩住使用私钥的代码的位置，并将其提取到攻击者服务器
Frida
将您自己的脚本注入黑盒进程。挂钩任何功能，监视加密API或跟踪私有应用程序代码，不需要任何源代码。编辑，点击保存，立即查看结果。全部没有编译步骤或程序重新启动。
xPosed
Xposed是一个框架，它使用户可以轻松地将附件（称为模块）应用于ROM。您不必使用新的ROM来获取特定功能，而可以使用Xposed将单个功能添加到您正在使用的任何ROM中，甚至只是库存ROM。
- 应用程序使用密码保护Excel工作表并将其导出。
只有用提供的密码导出的Excel工作表可以再次导入。
正如我之前在此答案中已经提到的那样，Frida和XPosed可用于在运行时自检和检测代码。
攻击者可以使用其中一种工具来挂接表明文档是否正确签名的函数，并始终返回true，从而绕过移动应用程序代码中随附的所有预期安全机制。这是我之前提到的使用Frida或xPosed在运行时提取私钥的一种替代方法。
- 想要导出excel的用户必须使用具有Google登录功能的Google帐户登录。
- 我的应用向Google请求登录令牌（已通过sha签名验证）
- 登录令牌已发送到我的服务器（HTTPS POST）
- 我的服务器验证令牌是Google验证的有效令牌。文档：https://developers.google.com/identity/sign-in/android/backend-auth
这4个步骤仅确定请求者，换句话说，是请求的用户，但不提供任何形式的目标代表用户提出了请求。
有关更深入的解释，建议您阅读我写的文章，特别是以下部分：Do You Know The Difference Between Who And What Is Communicating With Your Api Server?：
谁是移动应用程序的用户，我们可以通过多种方式进行身份验证，授权和标识，例如使用OpenID Connect或OAUTH2流。
什么是向API服务器发出请求的东西。它确实是您的移动应用程序的真正实例，还是机器人，自动脚本或攻击者使用诸如Postman之类的工具手动在您的API服务器上戳戳？
您可能会感到惊讶，攻击者是您试图绕过系统的真正用户。
要解决警告1，您必须始终将私钥保留在后端服务器中，并且从不将其发送给移动应用任何响应。
可以通过不在移动应用程序中签名或验证文档来解决警告2，而是在后端服务器中进行操作，并且必须确保后端服务器知道谁和< strong>什么正在发出请求。
警告3，它已经部分解决，一旦您知道请求中有谁是谁，您只需要实现一个强大的解决方案就可以知道是什么代表用户。
识别向后端服务器发出请求的方式的最常见方式是在请求标头中使用秘密，您可能将其称为APi-Key， Access-Token或其他名称，但是您可以在文章Steal That Api Key With A Man In The Middle Attack中看到如何通过中间人（MitM）攻击轻松绕过这种方法：
因此，在本文中，您将学习如何设置和运行MitM攻击以在您控制的移动设备中拦截https流量，以便您可以窃取API密钥。最后，您将在更高层次上看到如何缓解MitM攻击。
可以使用更可靠的解决方案，其中另一台服务器证明移动应用程序的完整性，这将使后端服务器知道何时信任什么发出请求，并且此概念是被移动应用证明所熟知。
我在The Role of Mobile App Attestation部分写的一篇文章中更详细地说明了移动应用证明服务的作用：
移动应用程序证明服务的作用是验证发送请求的什么，从而仅响应来自真正移动应用程序实例的请求，并拒绝来自未授权来源的所有其他请求。
为了知道什么正在将请求发送到API服务器，移动应用程序证明服务将在运行时高度确定您的移动应用程序是否存在已被篡改/重新打包，未在有根设备中运行，尚未被工具框架（Frida，xPosed，Cydia等）钩住，也不是中间人攻击（MitM）的对象。这是通过在后台运行SDK来实现的，该SDK将与在云中运行的服务进行通信，以证明移动应用程序及其所运行的设备的完整性。
在成功证明移动应用程序完整性后，将发布并使用一个秘密的短时间JWT令牌进行签名，该秘密只有云中的API服务器和移动应用程序证明服务才能知道。在证明失败的情况下，将使用错误的机密对JWT令牌进行签名。由于移动应用程序不知道移动应用程序证明服务使用的秘密，因此即使在应用程序被篡改，在有根设备中运行或通过连接通信时，也无法在运行时对其进行反向工程这是MitM攻击的目标。
移动应用必须在每个API请求的标头中发送JWT令牌。这允许API服务器仅在它可以验证JWT令牌已使用共享密钥签名且尚未过期时才服务请求。所有其他请求将被拒绝。换句话说，有效的JWT令牌会告诉API服务器发出请求的是上传到Google或Apple商店的真正的移动应用程序，而无效或丢失的JWT令牌则意味着发出请求的内容无权这样做，因为它可能是机器人，重新打包的应用或进行MitM攻击的攻击者。
虽然构建自己的Mobile App Attestation服务并不容易，但由知识渊博的工程师团队进行操作是可行的，并且要记住的主要一点是，SDK不执行任何决策，只是对随机响应服务器面临的挑战是，它是决定移动应用程序完整性的责任人。
您当前的防御措施要比最初的防御措施要好，并且您还有改进的余地，在提高移动应用程序和后端服务器的安全性方面应该付出多少努力，可能需要与规范您所要采取的措施相平衡这样做，您和您的团队可以使用的知识和资源，并与您所保护资产的价值成正比。
最后，我强烈建议您注意第1和第2条，并尝试第3条。
我一直想推荐这个非常有价值的资源OWASP Mobile Security Testing Guide
移动安全测试指南（MSTG）是用于移动应用安全开发，测试和逆向工程的综合手册。
答案 1 :(得分：0)
首先，即使您将其编译为本地C文件，也没有100％安全的存储方式。
要隐藏它们，您可以在执行时对其进行加密和解密。要加密您的字符串并将虚假代码注入丢失的黑客，您可以尝试以下Gradle插件：https://github.com/christopherney/Enigma