当开发一个应用或评估其面对的威胁时，需要将用户设备上的其他应用考虑进来。设备上任何恶意的第三方应用程序都能通过IPC机制与其他应用交互，也能窃取用户的私人信息。AppStore的应用程序审查是对抗这些恶意程序最有力的武器。

苹果公司没有公开披露他们的审查技术，而该技术主要用来检查应用能否满足AppStore的上架要求。可以确定的是，苹果使用了二进制分析和动态测试技术。这一过程可以将绝大部分带有明显恶意的应用拒之门外，也阻止了一些苹果不喜欢的应用上架(比如多种通信应用，色情或者重口味的应用)。

尽管苹果公司付出了很大努力来确保用户可以用到安全和高质量的应用，但事实证明，一个中等水平的攻击者完全有能力伪装一个动态代码更新应用，让他通过苹果商店的审查。主要有以下几个方式。

WebKit桥接：

基于WebKit桥接，可以通过JavaScript使用一些iOS的原生API，比如获取用户位置和使用媒体服务。PhoneGap就是一个典型的框架，以及最近很火的JSPatch。这种方式可以提供能多有用的功能，但使用它们也意味着应用程序的许多逻辑要写成JavaScript，因此不需要打包到应用中。举个例子，一个开发者可以使用JavaScript实现一个常规的打开文件功能，然后在应用审核期间不做任何的恶意操作。一旦审核通过，开发者可以修改设备的JavaScript，从而读取设备上那些本应该是禁区的数据。当然，现在这种热更新已经被苹果明令禁止了。所有使用了热更新框架的开发者都收到了苹果发的警告邮件，限定以后的版本不需使用热更新，不然可能会导致应用程序下架。但是对于Web应用来说，却没有什么明确的限制。还有一些使用了React Native框架的应用程序也没有收到警告，当然，这也不意味着以后苹果不会封杀它，毕竟他的创造者Facebook也只是在一些小应用上使用了这个框架。

动态修复：

通常来说，如果一段原生代码没有经过苹果发布的密钥签名认证，应用程序则无法运行它。如果苹果的签名验证逻辑中存在bug或漏洞，那么可能就会允许下载和执行原生代码。iOS有一个特性，前面的文章提到过，可以让程序分配一段没有NX保护的内存区块，该区块可读可写，甚至可以执行，里面运行的代码也不需要经过签名验证。这一机制被苹果用在了Safari的JIT编辑器上，以便实现一些功能，但是这就给了攻击者可趁之机。毕竟有代码的地方就可能出现漏洞，这样第三方应用程序就可以执行相同的把戏。最著名的例子就是Charlie Miller的破解程序，他破解了这个特性。这就意味着原生代码不需要签名认证就可以下载并执行。Miller向AppStore提交了一个股票代码查询应用InstaStock来演示这一过程。在应用审查期间，该应用安分守己，不进行任何恶意或者异常操作。但是一旦通过审核，Miller可以远程遥控该应用程序下载新的，未经签名的代码并执行，整个过程毫无阻碍。当然，现在这个漏洞已经被补上了，但是他却为我们如何骗过审核提供了思路。

故意植入不安全代码：

这个绕过AppStore审查的方法很有趣，它会让你的应用变得更加脆弱，很容易受到远程攻击。乔治亚理工学院曾开发过一款用来概念演示的应用Jekyll，他主要用来演示应用内核的缓冲区溢出。恶意代码被打包在应用程序自身之中以便可以顺利获得签名，同样在审查时不进行任何恶意操作，不去调用这些代码。一旦获准上架，开发者能够利用缓冲区溢出的漏洞改变应用程序的控制流，使其导向隐藏的恶意代码。这些代码能够使用苹果的私有框架，进而操控设备的蓝牙、短信甚至其他模块。

内嵌解释器：

过去几年，苹果在这方面的政策已经发生了改变，有许多产品(主要是游戏)会使用一个内嵌的Lua解释器来执行大部分的内在逻辑。当然了，过了这么多年，以内嵌解释器为媒介的恶意行为还没有见诸报端，毕竟相对于JavaScript直接调用原生代码来说，Lua解释器对于系统的原声API的操控还是十分受限的，你只能在一个安全的API范围内进行操作。但是，恶意应用可以通过一个类似的解释器来动态下载代码，并在内存中执行。当然，在AppStore的审核中这些恶意代码还是会隐藏自己。通过此方法我们能增加一个新的功能，行为不端的开发者也能较为便利的添加一个恶意功能。

其实AppStore的审核只能清除那些简单的恶意程序，但是恶意程序的确可以从审查人员的眼皮子底下溜走。时刻记住这一点，并在你的应用程序中用代码做好防御，不能假定操作系统中的其他程序都是善意的。