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

Posted 2023-02-23

【中文标题】如何确保我的 iOS 应用程序的完整性？

【英文标题】：How can I ensure the integrity of my iOS app?

【发布时间】：2019-09-25 09:15:22

【问题描述】：

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

我在网上找不到太多信息 - 大多数库/sn-ps 已经有 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

【问题讨论】：

在非越狱设备上您无需担心。在越狱设备上，这基本上是没有意义的；如果攻击者可以修改您的应用程序，那么他们可以修改您的应用程序中检查您的应用程序的部分，以便它只是说“一切都很好”。从本质上讲，您不能信任不受您控制的硬件。

同意。如果有办法可靠地做到这一点，Apple 会首先使用它来防止越狱。如果您有足够的预算来配备一个专门从事此工作的团队，那么他们可以持续做一些事情来试图领先于攻击者。如果您没有安全团队的预算，那么已经击败 Apple 的人不会轻易绕过的解决方案。

这个简短的版本是你的应用程序不能依赖它自己的完整性。如果您有服务器，它必须接受应用程序不可信的事实。有关更多信息，请参阅 ***.com/questions/9448632/… 和 ***.com/questions/9181186/…

【参考方案1】：

您当前的方法

我目前的方法是计算应用签名（C 代码）并将其与从服务器加载的一组签名进行比较。

我需要提醒您，攻击者在有根手机中将能够在运行时拦截您的代码并修改其行为，这意味着您检测签名正常的逻辑将始终返回 @987654329 @。他们通过使用像Frida这样的内省框架来做到这一点：

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

您的要求

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

如果这个要求只是为了保护你的应用程序不运行在 root 设备中，那么检查应用程序的签名是不够的，一旦设备被 root 了，它上面的任何应用程序都可以很容易地被操纵，就像我已经说过的那样提及。保护应用程序免受设备本身的攻击是一项艰巨的任务，就像与攻击者玩猫捉老鼠游戏一样，试图在游戏中保持领先。您将需要使用应用程序保护来检测应用程序是否在越狱设备中运行、是否附加了自省框架、是否在模拟器中运行、是否附加了调试器等。这是一个永无止境的游戏攻击者和他们有一个巨大的优势，他们可以投入所有的资源和时间来破坏你的应用程序，如果这对他们来说是值得的，但你可能没有相同的人力资源、时间和金钱来投资这个游戏。无论您决定如何玩游戏，都可以随时使用Apple Device Check API 在 API 服务器中标记特定设备不可信。

如果检查 iOS 应用签名的要求更符合保护 API 服务器不接收来自您上传到 Apple 商店的非正版 iOS 应用的请求，那么可能会有更好的解决方案，并以Mobile APP Attestation的名称而闻名。因此，如果这也在您的要求范围内，您应该继续阅读，否则请跳过它。

在深入探讨移动应用程序证明概念之前，我想先澄清一个关于WHO 和WHAT 正在访问 API 服务器的误解。

访问 API 服务器的对象和对象的区别

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

因此，将移动应用替换为网络应用，并继续围绕这张图片进行类比。

Intended Communication Channel 表示 Web 应用程序正按您的预期被合法用户使用，没有任何恶意，从浏览器与 API 服务器通信，不使用 Postman 或使用任何其他工具来执行中间人(MitM) 攻击。

实际通道可能代表几种不同的场景，例如具有恶意意图的合法用户可能正在使用 Curl 或 Postman 之类的工具来执行请求，黑客使用 MitM 攻击工具（例如 MitmProxy）来了解通信的方式Web 应用程序和 API 服务器之间正在完成，以便能够重放请求，甚至自动攻击 API 服务器。许多其他情况也是可能的，但我们不会在这里一一列举。

我希望现在您可能已经知道为什么 WHO 和 WHAT 不一样，但如果不一样，一会儿就会清楚。

WHO 是网络应用的用户，我们可以通过多种方式进行身份验证、授权和识别，例如使用 OpenID Connect 或 OAUTH2 流。

OAUTH

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

OpenID Connect

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

虽然用户身份验证可能会让 API 服务器知道 谁 正在使用 API，但它不能保证请求源自您所期望的 WHAT，浏览器是您的网络应用程序应该由真实用户运行。

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

令您惊讶的是，您最终可能会发现它可能是手动操作请求的合法用户之一，也可能是试图游戏化并利用网络应用提供的服务的自动脚本。

好吧，为了识别 WHAT，开发人员倾向于使用通常在 Web 应用程序标头中发送的 API 密钥。一些开发人员加倍努力并在运行时在 Web 应用程序中计算密钥，在混淆的 javascript 中，因此它成为运行时机密，可以通过反混淆工具进行逆向工程，并通过检查 Web 应用程序和 API 之间的流量使用 F12 或 MitM 工具的服务器。

以上文章摘自我写的一篇文章，题为为什么您的移动应用程序需要 API 密钥？。虽然在移动应用程序的上下文中，整体想法在 Web 应用程序的上下文中仍然有效。你希望你能完整阅读这篇文章here，这是关于 API 密钥的系列文章中的第一篇。

移动应用证明

使用移动应用证明解决方案将使 API 服务器能够知道什么正在发送请求，从而允许仅响应来自真正的移动应用的请求，同时拒绝来自不安全的所有其他请求来源。

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

MiTM Proxy

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

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

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

一旦移动应用程序不知道移动应用程序证明服务使用的秘密，即使应用程序被篡改、在有根设备中运行或通过正在成为中间人攻击的目标。

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

总结

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

加倍努力

OWASP Mobile Security Project - Top 10 risks

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