如何确保我的应用程序的后端 API 只能由应用程序本身访问？答案

【问题标题】：How to ensure that my app's backend API is only accessible by the app itself?如何确保我的应用程序的后端 API 只能由应用程序本身访问？
【发布时间】：2020-08-25 19:43:53
【问题描述】：

我的移动应用使用基于 HTTP 的 API，其端点不难发现，例如 https://<domain>/api/config 或 https://<domain>/api/login。

因此有人可以在应用程序中创建一个帐户，然后使用某些请求发出桌面应用程序（“流氓客户端”）中的凭据向/api/login 发送请求，然后在使用我的不记名身份验证方案“登录”之后，继续到其他端点查看从那里发送的数据。

此类尝试可能会让人们窥探有关其他用户的一些敏感数据，这些数据只能由应用程序内部访问。

在保证从我的后端 API 发送的任何数据只能由应用访问的过程中，有什么既定方法可以提高我的应用的安全性？

专门针对 iOS 应用，是否有任何框架可以实现这一点？

我的后端是 Nginx 和 Django。

【问题讨论】：

不可能。您的客户拥有的任何东西都可供其他任何花时间查看的人使用，这样他们就可以找到另一个客户。但除了真正的特殊情况和有趣的应用程序之外，没有人会这样做。例如，请参阅我的答案 here 或 here。
@GaborLengyel 不。
您只能使流氓客户端的开发更加困难，但完全防止这种情况是不可能的。目前，这样做的一种方法是使用带有服务器证书固定的 HTTPS、强制 HTTPS 客户端身份验证（证书+私钥必须在应用程序中得到很好的保护）以及具有反调试、反包括 Frida 和许多其他反逆向工程。
@Robert 谢谢。关于use HTTPS with server certificate pinning，SSL pinning 不是旨在确保客户端与真正的服务器后端而不是冒名顶替的服务器交谈吗？我的问题更多的是关于相反的情况：确保后端正在与正版应用程序对话。关于forced HTTPS client authentication，我不确定你的意思。
@DesmondHume 要了解通信有两种方法：反转应用程序（离线）并了解它使用哪些 API 或通过例如重定向应用程序和服务器之间的流量。 mitmproxy 让你直接看到所有的通信。使用证书固定攻击者首先必须打破这一点，然后才能访问传输的数据。 HTTPS cert based client auth：这是 HTTPS 的可选功能，可以由服务器强制执行。在这种情况下，如果客户端没有正确的证书+私钥，则无法建立 HTTPS 连接。

标签： ios api security

【解决方案1】：

映射 API

我的移动应用正在使用基于 HTTP 的 API，其端点不难发现，例如 https:///api/config 或 https:///api/login。

映射您的移动应用程序使用的所有 API 端点所需的只是让某人将您的移动应用程序安装在他们控制的设备中，并通过代理（例如 mitmproxy）代理请求：

一个交互式的支持 TLS 的拦截 HTTP 代理，供渗透测试人员和软件开发人员使用。

持有者授权令牌提取

因此有人可以在应用程序中创建一个帐户，然后使用某些请求发出桌面应用程序（“流氓客户端”）中的凭据向 /api/login 发送请求，然后在使用我的不记名身份验证“登录”之后方案，继续到其他端点以查看从那里发送的数据。

是的，您可以在应用程序中创建帐户并提取不记名身份验证令牌，为此您可以继续使用我提到的代理方法来映射所有 API 端点。您可以阅读this article 了解我如何使用 mitmproxy 提取 API 密钥，因此适用于您的不记名令牌场景。

mitmproxy 允许我们即时或在任何时间点拦截、操作和重播请求，因此是一个出色的工具，可以在您以普通用户身份使用移动应用程序时探索您的 API 并提取所有数据。

敏感数据访问

此类尝试可能会让人们窥探有关其他用户的一些敏感数据，这些数据只能由应用程序内部访问。

这似乎更像是您的移动应用程序和后端的设计问题，因为登录的用户永远不能以其他用户的身份访问 API 端点。

您还需要确保每个 API 端点严格只返回绝对必要的数据，以便移动应用程序执行其需要执行的操作。不幸的是，更多的时候不是开发人员拥有大量的 API 端点，这些端点会泄露大量信息，然后由消费者来过滤它需要的数据。不要这样做，而是使用角色来授权每个记录的用户在每个 API 端点中访问的数据量，因此允许在响应中根据其角色发送或多或少的数据。

要记住的另一件事是，开发人员倾向于在客户端执行过多的业务逻辑，并且这种方法还会导致 API 过于臃肿，并且如果 API 是唯一的 API，则可能会泄漏可能保留在服务器端的数据负责执行该业务逻辑。尝试将您的移动应用程序设计得尽可能愚蠢，并让它们将所有艰苦的工作委托给后端。这种方法的优势还在于无需发布新的移动应用即可轻松修复错误。

提高 API 安全性

在保证从我的后端 API 发送的任何数据只能由应用访问的过程中，有什么既定方法可以提高我的应用的安全性？

好吧，您给自己买了一个很难克服的挑战，但是虽然很难实现一个解决方案，让您的 API 服务器非常确信收到的请求确实来自您的真实实例移动应用。

因此，您似乎想锁定您的 API 服务器以仅接受来自您的移动应用程序的请求，如果是这种情况，请阅读 this reply 我提出的问题 如何保护 API REST for移动应用程序？查看保护 API 服务器和可能的更好解决方案的部分。

专门针对 iOS 应用程序，是否有任何框架可以实现这一点？

如果您已经阅读了我上面链接的回复，那么您现在应该知道您应该深入使用安全性，通过使用尽可能多的层，这是所有移动应用证明概念中最有效的。

请记住，如果您添加了更多安全层，攻击者将花费更多时间来克服所有这些层。这也提高了攻击者绕过所有攻击者所需的技能集的门槛，从而使脚本儿童和季节性攻击者望而却步。

顺便说一句，不要忘记始终将强大的代码混淆技术应用于您的代码库。

您想加倍努力吗？

在回答安全问题时，我总是喜欢参考 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 时提供最佳实践。

【讨论】：

【解决方案2】：

Here 是使用 JWT 的最佳实践。

在客户端，您创建令牌（为此有很多库），使用秘密令牌对其进行签名。您将它作为 API 请求的一部分传递，服务器将知道它是那个特定的客户端，因为请求使用其唯一标识符进行签名

编辑：根据 cmets 和讨论，达到完全的安全性是不可能的，但您可以使用上述博客文章实践使其更难。

【讨论】：

使用 JWT 的问题是你需要保守秘密，嗯，秘密。由于秘密需要在应用程序中，所以没有办法做到这一点（你可以让它变得困难，但并非不可能提取秘密）
当然，你是对的。但我认为基于用户凭据生成令牌太脆弱了。我们可以通过上述解决方案使其更强大。请提及您认为更好用的替代方案。