ios - 如何确保iOS应用程序的完整性？

Question

我要求必须检查我的Swift iOS应用程序的签名。
我认为这仅与越狱设备有关，因为iOS会自行检查完整性。

我在网上找不到太多-大多数图书馆/摘要都已经5年没有更新了。
我当前的方法是计算应用程序签名(C代码)，并将其与从服务器加载的一系列签名进行比较。一个数组，因为支持应用程序的多个版本。

关于此方法有什么想法或意见吗？也许与Swift不再相关了？

以下是一些可以激发我的解决方案的资源:

https://github.com/olxios/SmartSec_iOS_Security

https://github.com/project-imas/encrypted_code_modules/blob/master/ecm_app_integrity_check/ecm_app_integrity_check/app_integrity_check.m

Answer 1

您当前的方法

我当前的方法是计算应用程序签名(C代码)，并将其与从服务器加载的一系列签名进行比较。

我需要提醒您以下事实:攻击者可以在植根电话中在运行时拦截您的代码并修改其行为，这意味着您可以检测签名的逻辑将始终返回true。他们通过使用像Frida这样的自省框架来做到这一点:

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

您的要求

我要求必须检查我的Swift iOS应用程序的签名。我认为这仅与越狱设备有关，因为iOS会自行检查完整性。

好吧，如果此要求仅是为了保护您的应用程序免于在有根设备上运行，则仅检查应用程序的签名是不够的，一旦将设备植根后，就可以轻松地操纵它上的任何应用程序，正如我已经提到的那样。保护应用程序免受设备本身的攻击是一项艰巨的任务，就像通过尝试保持领先地位，与攻击者玩猫捉老鼠游戏一样。您将需要在应用程序保护中使用，以检测应用程序是否在越狱设备中运行，是否已安装了自省框架，是否正在模拟器中运行，是否已连接调试器等。这是一个永无止境的游戏，攻击者和他们具有巨大的优势，他们可以花所有的资源和时间来破坏您的应用程序(如果对他们而言值得)，但是您可能没有相同的人力资源，时间和金钱来投资该游戏。无论您决定如何玩游戏，都可以始终使用Apple Device Check API在API服务器中标记特定设备不可靠。
如果检查iOS应用程序签名的要求更符合保护API服务器免受来自不是您上载到Apple Store的正版应用程序的iOS应用程序的请求的保护，则可能有更好的解决方案，并且以Mobile APP Attestation的名称而闻名。因此，如果这也在您的要求范围内，则应继续阅读，否则请跳过。
在深入探讨移动APP认证概念之前，我想先清除一个关于的误解，WHO 和 正在访问API服务器。
WHO和访问API服务器之间的区别
为了更好地理解WHOt 和正在访问API服务器的之间的区别，让我们使用以下图片:

因此，将移动应用替换为网络应用，并继续按照我对此类图片的类推。
预期的通信渠道表示合法用户在没有任何恶意意图的情况下按预期使用的Web应用程序，通过浏览器与API服务器进行通信，而不使用Postman或使用任何其他工具来执行中间操作(MitM)攻击。
实际渠道可能代表几种不同的情况，例如具有恶意意图的合法用户可能正在使用Curl或Postman等工具来执行请求，黑客使用MitM攻击工具(例如MitmProxy)来了解网络之间的通信方式应用程序和API服务器已经完成，以便能够重播请求，甚至自动对API服务器进行攻击。其他许多情况也是可能的，但在此我们将不逐一列举。
我希望到现在为止您可能已经有了一个线索，为什么 WHO 和 WHAT 并不相同，但是如果不是这样的话，这将很快变得清晰。
WHO 是Web应用程序的用户，我们可以通过多种方式来进行身份验证，授权和标识，例如使用OpenID Connect或OAUTH2流。

OAUTH
通常，OAuth代表资源所有者向客户端提供对服务器资源的“安全委派访问”。它为资源所有者指定了一种在不共享其凭据的情况下授权第三方访问其服务器资源的过程。 OAuth专为与超文本传输​​协议(HTTP)配合使用而设计，本质上允许在资源所有者的批准下，授权服务器将访问 token 发布给第三方客户端。然后，第三方使用访问 token 访问资源服务器托管的受保护资源。
OpenID Connect
OpenID Connect 1.0是基于OAuth 2.0协议的简单身份层。它允许客户端基于授权服务器执行的身份验证来验证最终用户的身份，并以可互操作且类似于REST的方式获取有关最终​​用户的基本配置文件信息。

尽管用户身份验证可以让API服务器知道，谁是正在使用API​​，但它不能保证请求源自您期望的，但浏览器是您的Web应用程序的运行对象，并且是真实用户。
现在，我们需要一种方法来识别，即在调用API服务器，这比大多数开发人员想象的要棘手得多。 是什么是向API服务器发出请求的东西。它真的是Web应用程序的真实实例，还是使用诸如Postman之类的工具通过API服务器手动访问的机器人，自动脚本或攻击者？
令您惊讶的是，您可能最终发现它可能是手动处理请求的合法用户之一，或者是试图游戏化并利用Web应用程序提供的服务的自动脚本。
好吧，为了识别和，开发人员倾向于求助于通常在Web应用程序标头中发送的API密钥。一些开发人员会加倍努力，并在运行时在经过混淆的javascript内的Web应用程序中计算密钥，因此它成为运行时机密，可以通过除臭工具以及检查Web应用程序与API之间的流量进行逆向工程F12或MitM工具的服务器。
以上文章摘自我写的一篇文章，标题为《为什么您的移动应用程序需要API密钥？》。在移动应用程序的上下文中，总体思想在Web应用程序的上下文中仍然有效。您希望可以阅读完整的here文章，这是有关API密钥的系列文章中的第一篇。
行动应用程式证明
使用移动应用证明解决方案将使API服务器知道 正在发送请求，从而仅响应来自真实移动应用的请求，同时拒绝来自不安全来源的所有其他请求。
移动应用程序认证解决方案的作用是在运行时保证您的移动应用程序未被篡改，不在有根设备中运行，没有被Frida之类的框架检测，未被MitM攻击，并且可以实现这一目标通过在后台运行SDK。在云中运行的服务将挑战应用程序，并且基于响应，它将证明正在运行的移动应用程序和设备的完整性，因此SDK绝不负责任何决定。
MiTM Proxy

面向渗透测试人员和软件开发人员的交互式TLS拦截HTTP代理功能。

在成功证明移动应用程序完整性后，将发布并使用一个短时生存的JWT token 进行签名，并秘密地告知只有API服务器和云中的“移动应用程序证明”服务。在移动应用程序证明失败的情况下，将使用API​​服务器不知道的秘密对JWT token 进行签名。
现在，应用程序必须随每个API一起发送，并在请求的标头中调用JWT token 。这将允许API服务器仅在它可以验证JWT token 中的签名和到期时间时才服务请求，而在验证失败时拒绝它们。
一旦移动应用程序不知道移动应用程序证明服务使用的机密，就无法在运行时对其进行反向工程，即使该应用程序被篡改，在有根设备中运行或通过正在作为连接的连接进行通信中间攻击中一名男子的目标。
移动应用证明服务已经作为Approov的SAAS解决方案存在(我在这里工作)，该服务为多个平台(包括iOS，Android，React Native等)提供SDK。集成还需要在API服务器代码中进行少量检查，以验证由云服务发出的JWT token 。 API服务器必须能够执行此检查，才能决定服务哪些请求以及拒绝哪些请求。
概要
最后，必须根据您要保护的内容的价值以及此类数据的法律要求(例如欧洲的GDPR法规)来选择用于保护API服务器的解决方案。
多走一英里
OWASP Mobile Security Project - Top 10 risks

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