与在 Android 上提供 API 的 nodejs 服务器建立安全连接

Question

我有一个存储私人信息的网站，可以通过使用秘密 api 密钥的请求访问。

我的Android 应用程序必须访问该私人信息，为此它使用代理服务器存储并使用秘密 api 密钥与网站进行通信。

问题是只要使用Wireshark，或者在app资源文件中找到字符串，就有人可以看到代理服务器的url并使用它从网站上获取私人数据

我怎样才能使这个系统安全？我如何确定除了 Android 应用程序之外没有其他人可以使用代理？

谢谢！

Answer 1

我有一个存储私人信息的网站，可以通过使用秘密 api 密钥的请求进行访问。

从您将秘密放在客户端的那一刻起，它就不再是秘密，因为现在是公开的，任何人都可以通过对应用程序进行逆向工程或通过代理拦截流量或仅使用您提到的工具查看流量来查看它，线鲨。

我的 Android 应用程序必须访问该私人信息，并为此使用代理服务器存储并使用秘密 api 密钥与网站进行通信

使用代理服务器并不能解决问题，因为代理服务器不知道什么是调用它。就目前而言，代理服务器对知道如何调用它的公众开放，正如您已经知道并指出的：

问题是，只要使用Wireshark，或者在app资源文件中找到字符串，就有人可以看到代理服务器的url并使用它从网站上获取私人数据。

另一种方法是使用像MiTM Proxy这样的代理工具，在我看来，它可以更轻松地提取 API 密钥，正如您在使用中间人攻击窃取 API 密钥一文中所见：

虽然我们可以使用 JNI/NDK 等高级技术将 API 密钥隐藏在移动应用程序代码中，但它不会阻止某人执行 MitM 攻击以窃取 API 密钥。事实上，中间人攻击很容易，甚至可以由非开发人员实现。

解决您的问题

我怎样才能使这个系统安全？我如何确定除了 Android 应用程序之外没有其他人可以使用代理？

好吧，你给自己买了一个很难解决的问题，很多人会说这只会让攻击者更难解决，这在一定程度上是正确的，因为很多开发人员都不知道 Mobile App Attestation 概念，它允许后端服务器只处理来自原始应用程序的请求。

在向您解释这个概念之前，我想澄清开发人员之间关于WHO与WHAT正在访问您的后端服务器的常见误解。

WHO 和 WHAT 访问 API 服务器的区别

为了更好地理解访问 API 服务器的WHO和WHAT之间的区别，让我们使用这张图：

预期通信通道表示移动应用程序按照您的预期使用，由没有任何恶意意图的合法用户使用，使用移动应用程序的未篡改版本，并直接与 API 服务器通信，而不会受到中间人的攻击。

实际渠道可能代表几种不同的场景，例如具有恶意意图的合法用户可能使用重新包装的移动应用程序版本，黑客使用移动应用程序的正版版本，而中间人对其进行攻击，以了解如何正在完成移动应用程序和 API 服务器之间的通信，以便能够自动攻击您的 API。许多其他场景也是可能的，但我们不会在此一一列举。

我希望现在你可能已经知道为什么WHO和WHAT不一样了，但如果不一样，马上就会明白。

该世界卫生组织是移动应用程序，我们可以验证，授权和以多种方式确定，比如使用OpenID登录连接或流的oauth2的用户。

身份验证

通常，OAuth 代表资源所有者向客户端提供对服务器资源的“安全委托访问”。它指定了资源所有者授权第三方访问其服务器资源而不共享其凭据的过程。OAuth 专为与超文本传输​​协议 (HTTP) 一起使用而设计，本质上允许在资源所有者批准的情况下，由授权服务器向第三方客户端颁发访问令牌。然后第三方使用访问令牌访问由资源服务器托管的受保护资源。

OpenID 连接

OpenID Connect 1.0 是 OAuth 2.0 协议之上的一个简单的身份层。它允许客户端根据授权服务器执行的身份验证来验证最终用户的身份，并以可互操作和类似 REST 的方式获取有关最终​​用户的基本配置文件信息。

虽然用户认证可以让API服务器知道世卫组织正在使用的API，它不能保证请求源自什么你期望的那样，移动应用程序的原始版本。

现在我们需要一种方法来识别什么在调用 API 服务器，这里的事情变得比大多数开发人员想象的更棘手。在什么是发出请求到服务器API的东西。它真的是移动应用程序的真实实例，还是机器人、自动化脚本或攻击者使用 Postman 之类的工具手动浏览 API 服务器？

令您惊讶的是，您最终可能会发现它可能是使用重新打包的移动应用程序版本或试图游戏化并利用应用程序提供的服务的自动化脚本的合法用户之一。

好吧，为了识别WHAT，开发人员倾向于求助于 API 密钥，通常他们在移动应用程序的代码中硬编码。一些开发人员加倍努力并在移动应用程序中在运行时计算密钥，因此它成为运行时秘密，而不是在代码中嵌入静态秘密时的前一种方法。

以上文章摘自我写的一篇文章，题为为什么您的移动应用程序需要 API 密钥？，您可以在此处完整阅读，这是有关 API 密钥的系列文章中的第一篇。

第一个问题

我怎样才能使这个系统安全？

根据您的预算和资源，您可能会采用一系列不同的方法和技术来保护您的 API 服务器，我将开始列举一些最常用的方法，但在我这样做之前，我想留下以下说明：

作为最佳实践，移动应用程序或 Web 应用程序应仅与受您控制的 API 服务器进行通信，并且对第三方 API 服务的任何访问都必须由您控制的同一 API 服务器完成。通过这种方式，您可以将攻击面限制在一个地方，在那里您将使用尽可能多的防御层，以保护您所保护的对象的价值。

您可以从reCaptcha V3开始，然后是Web 应用程序防火墙(WAF)，最后是用户行为分析(UBA) 解决方案（如果您负担得起）。

谷歌reCAPTCHA V3：

reCAPTCHA 是一项免费服务，可保护您的网站免受垃圾邮件和滥用。reCAPTCHA 使用先进的风险分析引擎和自适应挑战来防止自动化软件在您的网站上从事滥用活动。它做到了这一点，同时让您的有效用户轻松通过。

...帮助您在没有任何用户摩擦的情况下检测网站上的滥用流量。它根据与您网站的交互返回一个分数，并为您提供更大的灵活性来采取适当的行动。

WAF - Web 应用程序防火墙：

Web 应用程序防火墙（或 WAF）过滤、监视和阻止进出 Web 应用程序的 HTTP 流量。WAF 与常规防火墙的区别在于 WAF 能够过滤特定 Web 应用程序的内容，而常规防火墙则充当服务器之间的安全门。通过检查 HTTP 流量，它可以防止源自 Web 应用程序安全缺陷的攻击，例如 SQL 注入、跨站点脚本 (XSS)、文件包含和安全配置错误。

UBA - 用户行为分析：

Gartner 定义的用户行为分析 (UBA) 是一个关于检测内部威胁、针对性攻击和金融欺诈的网络安全过程。UBA 解决方案着眼于人类行为模式，然后应用算法和统计分析从这些模式中检测有意义的异常——表明潜在威胁的异常。UBA 不跟踪设备或安全事件，而是跟踪系统的用户。Apache Hadoop 等大数据平台允许它们分析 PB 级数据以检测内部威胁和高级持续威胁，从而增强 UBA 功能。

所有这些解决方案都基于否定识别模型工作，换句话说，他们尽力通过识别什么是坏而不是什么来区分好与坏，因此尽管使用了先进的技术，但它们仍然容易出现误报其中一些，如机器学习和人工智能。

因此，您可能会发现自己经常不得不放松阻止对 API 服务器的访问的方式，以免影响好用户。这也意味着该解决方案需要持续监控以验证误报没有阻止您的合法用户，同时他们正确地阻止未经授权的用户。

关于为移动应用提供服务的 API，可以通过使用移动应用证明解决方案来使用肯定的识别模型，该解决方案向 API 服务器保证请求可以被信任而不会出现误报，我将解释它作为对您的第二个问题的答复.

第二个问题

我如何确定除了 Android 应用程序之外没有其他人可以使用代理？

正如我在回答开头提到的那样，移动应用证明概念可能是您解决问题的最佳选择。

移动应用证明解决方案的作用是在运行时保证您的移动应用没有被篡改，没有在有根设备中运行，没有被 xPosed 或 Frida 之类的框架所检测，没有受到中间人攻击，这是通过在后台运行 SDK 来实现的。在云中运行的服务将挑战应用程序，并根据响应证明移动应用程序和设备运行的完整性，因此 SDK 永远不会对任何决定负责。

弗里达

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

摆姿势

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

中间人代理

用于渗透测试人员和软件开发人员的交互式 TLS 拦截 HTTP 代理。

成功证明移动应用程序完整性后，将发布一个短期存在的 JWT 令牌，并使用只有 API 服务器和云中的移动应用程序证明服务知道的秘密进行签名。如果移动应用程序认证失败，JWT 令牌会使用 API 服务器不知道的秘密进行签名。

现在，应用程序必须随每个 API 调用发送请求标头中的 JWT 令牌。这将允许 API 服务器仅在可以验证 JWT 令牌中的签名和到期时间时才提供请求，并在验证失败时拒绝它们。

一旦移动应用程序认证服务使用的秘密不被移动应用程序知道，即使应用程序被篡改、在有根设备中运行或通过连接进行通信，也无法在运行时对其进行逆向工程。中间人攻击的目标。

移动应用证明服务已经作为 Approov 的 SAAS 解决方案存在（我在这里工作），它为多个平台提供 SDK，包括 iOS、Android、React Native 等。集成还需要对 API 服务器代码进行少量检查，以验证云服务发布的 JWT 令牌。此检查对于 API 服务器能够决定提供哪些请求以及拒绝哪些请求是必要的。

结论

最后，必须根据您要保护的内容的价值以及对此类数据的法律要求（如欧洲的 GDPR 法规）来选择用于保护 API 服务器的解决方案。

你想多走一英里吗？

OWASP 移动安全项目 - 十大风险

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