如何通过哈希比较限制 API 密钥的使用

Posted 2023-02-23

【中文标题】如何通过哈希比较限制 API 密钥的使用

【英文标题】：How to restrict usage of an API key with Hash comparison

【发布时间】：2020-08-25 22:39:24

【问题描述】：

我目前在我的 Android 应用中使用 Spotify，但我需要使用 Secret 才能刷新令牌等。我想将我的 Backend 中的秘密传输到应用程序，因此秘密不驻留在 APK 中，并且在反编译时无法找到。我已经阅读了很多关于在您的应用程序中保护机密的内容，通过代理等各种方式，只需使用您自己的后端，将代码放入应用程序中的本机 C++ 代码 (NDK) 或使用应用程序的哈希来确定是否应用程序正在调用后端，而不是在他的计算机后面试图窃取秘密的​​某个人。

找到的选项：

代理：这意味着通过我自己的服务器路由它，不想要那个 自己的后端：与代理相同，不希望所有请求都通过我自己的服务获得 本机代码：使用它似乎会减慢反编译器的速度，但不会阻止它们 Hash：据我所知，this 帖子提出了一些我认为很奇怪的事情。它正在检索 SHA-1 并将其传递到网络标头以验证应用程序是否正在调用。奇怪的是，当您只是unzip APK 文件时，运行 printcert (keytool -printcert -file CERT.RSA) 命令将显示 APK 的所有 SHA 和 MD5 哈希值。据我所知，这并非万无一失，因为有人可以获取 APK 文件的哈希值并将其提交给服务器。

有没有其他方法可以解决这个问题？

【问题讨论】：

重复Best practice for storing and protecting private API keys in applications

@sonnet 对于某些部分，我发现的一些解决方案没有在该帖子中提及，因此它实际上不算重复

【参考方案1】：

人类创造的一切都可以被人类分解——没有完全安全的选择。

不过，您可以尝试的事情很少。

使用end-to-end 加密与您的服务器建立安全连接，然后将您的密钥从您的后端发送到您的应用程序。将通过KeyStore 保护的机密存储在 SharedPrefs 或文件或数据库中。

您还可以利用基于 Vernam 算法的 one-time pad 密码。它具有绝对的密码强度，因此无法破解。与 Diffie-Hellman 结合使用可能会大大提高安全性。

尽管如此，它仍然可以被破解 - 通过在应用程序处于活动状态并已秘密解密时通过根设备上的内存扫描，通过中间人攻击等。正如我所说 - 一切都可以被破坏（现在可能除了 Vernam 算法）。

不过不要太在意它 - 犯罪分子很难严重滥用您的秘密。一般来说，他们甚至不会那么在意这些东西。

希望这个答案能对你有所帮助。

【参考方案2】：

您的问题

我目前在我的 android 应用中使用 Spotify，但我需要使用 Secret 才能刷新令牌等。我想将秘密从我的后端传输到应用程序，因此秘密不驻留在 APK 中，并且在反编译时无法找到。我已经阅读了很多关于在您的应用程序中保护机密的内容，通过代理等各种方式，只需使用您自己的后端，将代码放入应用程序中的本机 C++ 代码 (NDK) 或使用应用程序的哈希来确定是否应用程序正在调用后端，而不是在他的计算机后面试图窃取秘密的​​某个人。

恭喜您努力理解这个问题，您似乎在很大程度上理解了移动应用程序中的秘密总是可以通过静态二进制分析来提取，但我没有看到任何提到像这样的检测框架：

Frida

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

或

xPosed

Xposed 是一个模块框架，可以在不触及任何 APK 的情况下改变系统和应用的行为。这很棒，因为这意味着模块可以在不同版本甚至 ROM 上工作而无需任何更改（只要原始代码没有太大更改）。它也很容易撤消。

但还有更多其他的存在，它们都将在运行时挂钩到您的代码并提取您存储在移动应用程序中的任何秘密，无论您存储它的安全性如何，即使您使用硬件支持的密钥库，运行在可信的执行环境：

Android Hardware-backed Keystore

片上系统 (SoC) 中可信执行环境的可用性为 Android 设备提供了一个机会，可以为 Android 操作系统、平台服务甚至第三方应用提供硬件支持的强大安全服务.

在某些时候，需要使用从该密钥库中检索到的秘密来向您的第三方服务发出请求，此时攻击者需要做的就是挂上对该函数的调用并提取秘密当传递给它时。

所以无论你最终做什么，移动应用程序中的秘密总是可以被提取出来，这取决于攻击者的技能和他愿意投入的时间和精力。

话虽如此，但我一直建议开发人员不要这样做，即从他们的移动应用程序中调用第三方服务。

通过移动应用访问第三方服务

找到的选项：

代理：这意味着通过我自己的服务器路由它，不想要那个 自己的后端：和代理一样，不希望所有请求都通过我自己的服务

是的，我了解到您不想使用代理或后端，但这是您确保访问第三方服务（在本例中为 Shopify）的最佳机会。

我写了this article，解释了为什么你不应该在移动应用中这样做，我引用的地方：

通常，所有第三方 API 都需要 API 密钥、访问令牌或其他某种机制形式的秘密，以便远程客户端向希望与之通信的后端服务器标识自己。这就是从您的移动应用程序中访问它的问题的症结所在，因为您需要在代码中发送所需的秘密（上图中的彩色键）。

现在您可能会说您在代码中混淆了秘密，将其隐藏在本机 C 代码中，在运行时动态组装，甚至加密。然而，最终，为了提取这个秘密，攻击者需要做的就是通过静态二进制分析对二进制文件reverse engineer 进行操作，或者在运行时将Frida 之类的检测框架挂钩到将返回秘密的函数中。或者，攻击者可以通过执行MitM (man-in-the-middle) 来检查移动应用程序与其连接的第三方 API 之间的流量。

有了这个秘密，攻击者可以对组织造成很大的破坏。损害可能是金钱、声誉和/或监管方面的。在财务上，攻击者可以使用提取的秘密以您的名义访问您的云提供商和按调用付费的第三方 API，从而导致您产生额外费用。此外，您可能会因泄露可能出售给您的竞争对手或用于实施欺诈的数据而受到经济损失。当攻击者使用提取的秘密代表您在社交网络上发帖时，您的声誉可能会受到影响，从而造成公关噩梦。当攻击者使用第三方 API 并违反其条款和条件（例如频繁使用 API 触发速率限制时），可能会造成另一次声誉损害，从而阻止您使用该服务，从而给您的最终用户带来痛苦。最后但并非最不重要的一点是，当提取的秘密是保护第三方 API 访问机密信息的唯一机制时，会引起监管问题。如果攻击者可以检索个人身份信息 (PII) 等机密信息，则可能会对您的企业执行与违反欧洲 GDPR 或加利福尼亚州新的 CCPA 数据隐私法有关的监管罚款。

因此，带回家的信息是，从您发布应用或将代码推送到公共存储库的那一刻起，您在代码中发布的任何秘密都必须被视为公开。现在应该很清楚，最好的方法是完全避免从移动应用程序中访问第三方 API；相反，您应该始终将此访问权限委托给您可以信任和控制的后端，例如反向代理。

您现在可能会说问题刚刚从移动应用转移到反向代理或后端服务器，这是一件好事，因为后端或反向代理在您的控制之下，但移动应用不在您的控制范围内控制，因为它在客户端，因此攻击者可以为所欲为。

在后端或反向代理中，您不会向公众公开访问第三方服务的秘密，并且攻击者想要代表您对第三方服务进行的任何滥用都需要通过您控制的地方，因此您可以应用尽可能多的防御机制，这些防御机制是法律要求的。

深度安全

将代码放入本机 C++ 代码 (NDK)

当隐藏在原生 C 代码中的秘密时，通过静态二进制分析并不容易找到它，至少对于脚本小子和季节性黑客来说，它需要大多数人可能没有的更好的技能，因此我真的建议你将其用作额外的安全层，但要保护访问您自己服务的秘密，而不是我之前提到的第三方服务。

如果你真的决定听从我的建议，并转移你的努力来保护你可以控制的第三方秘密，比如你自己的后端，那么我建议你阅读my answer这个问题如何保护移动应用的 API REST？ 了解保护 API 服务器和可能的更好解决方案。

如果您阅读了上述答案，那么您已经意识到，如果您在后端保留对第三方服务的访问权限，您可以通过使用移动应用程序以非常高的信心将您的 API 服务器锁定到您的移动应用程序证明概念。

您想加倍努力吗？

我看到您消息灵通，因此您已经知道我将要分享的内容，但是在我对安全问题的任何回复中，我总是喜欢参考 OWASP 基金会的出色工作，因此如果您允许我会在这里做:)

对于移动应用

OWASP Mobile Security Project - Top 10 risks

OWASP 移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。

OWASP - Mobile Security Testing Guide:

移动安全测试指南 (MSTG) 是一本用于移动应用安全开发、测试和逆向工程的综合手册。

对于 APIS

OWASP API Security Top 10

OWASP API 安全项目旨在通过强调不安全 API 的潜在风险并说明如何降低这些风险，为软件开发人员和安全评估人员提供价值。为了实现这一目标，OWASP API 安全项目将创建和维护一份 API 安全风险前 10 名文档，以及一个文档门户，用于在创建或评估 API 时提供最佳实践。

【讨论】：

您的信息和想法对我帮助很大，非常感谢。不幸的是，没有真正的方法来保护它而不使用外部服务器。我想我会使用代理服务器，谢谢你的详尽解释！