16.1 前言
在移动互联网快速发展的今天，iOS应用由于直接运行在用户的手机上，与运行在服务器的后台服务相比，更有可能被黑客攻击。本文接下来将从三个方面概述iOS移动应用在安全方面所面临的挑战及应对措施。
16.2 网络安全
16.2.1 安全地传输用户密码
大部分iOS应用都需要联网， 通过和服务器进行通讯，获得最新消息并将内容展现给用户。由于网络传输过程中有可能经过不安全的中间节点，所以我们应该对数据加密保持敏感，以保证用户信息的安全。黑客可以在受害者的手机上设置网络通讯的代理服务器，从而截获所有的网络请求。即使是HTTPS的加密通讯，黑客也可以通过中间人攻击(Main-in-the-middle attack，是指攻击者与通讯的两端分别创建独立的联系，并交互其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制)来截获通讯内容。
黑客会在Mac上使用Chaler(http://www.charlesproxy.com)软件来将自己的电脑设置成代理服务器，从而截取应用的网络请求，分析目标应用在通讯协议上是否有安全问题。如果是在Windows环境下，则会使用Fidder(http://www.telerik.com/fiddler)软件。为了测试，我们选取了国内最大的两家租车公司神州租车和一嗨租车的iOS应用。
从下面两幅图可以看到，神州租车和一嗨租车在用户登录时，均采用明文的方式，将密码直接发送给服务器。其中一嗨租车不但采用明文方式发送密码，而且在发送时使用了HTTP GET方式，而GET的URL数据一般都会保存在服务器的access log中，所以黑客一旦攻破服务器，只需要扫描access log，则可以轻易获取所有用户的明文密码。神州租车虽然已经修改了登录协议，采用了POST的方式来登录，但传递的仍然是明文密码。
神州租车登录协议：
一嗨租车登录协议：
如果每一个应用都像以上两种那样明文传输用户密码，那么我们可以想象这样一个场景，黑客在咖啡馆或机场等一些公共场所，用自己的电脑设置一个与该场所名字相同的免费WiFi，那么受害者制药不小心使用了该WiFi，就可能泄漏自己的明文密码。大多数普通人，都会使用一样的密码登录他的所有的账号，这就意味着他的其他账号，例如淘宝或网上银行账号也有被盗的风险。
正确的做法应该是这样：事先生成一个用于加密的公私钥，客户端在登录时，使用公钥将用户的密码加密后，将密文传输给服务器。服务器使用私钥将密码解密，然后加盐(Salt：在密码学中，是指通过在密码任意固定位置插入特定的字符串，让散列后的结果和使用原始密码的散列结果不相符)之后再多次求MD5，之后再和服务器原来存储的用同样方法处理过的密码匹配，如果一致，则登录成功。这样，黑客即使截获了加密后的密文，由于没有私钥，也无法还原出原始的密码。而服务器即使被黑客攻陷，黑客除了暴力尝试，也无法从加盐和多次MD5后的密码中还原出原始的密码。这样就保证了用户密码的安全。
16.2.2 防止通讯协议被轻易破解
除了上面提到的明文传输密码的问题外，移动端应用还要面对黑客破解通讯协议的威胁。在成功破解了通讯协议后，黑客可以模拟客户端登录，进而伪造一些用户行为，可能对用户数据造成危害。例如腾讯出品的消除游戏”天天爱消除”，在淘宝上就有很多售价仅为1元的代练服务，如果真正时人工代练，是不可能卖这么便宜的，只可能是该游戏的通讯协议被破解，黑客制作出了代练的机器人程序。
通讯协议被破解除了对于移动端游戏有严重危害外，对于应用也有很大的危害。例如针对微信，黑客可以制作一些”僵尸“账号，通过向微信公共账号后台发送垃圾广告，达到盈利目的。而iPhone设备上的iMessage通讯协议据说也被破解了，所以很多iPhone用户会收到来自iMessage的垃圾广告。
对于以上提到的问题，开发者可以选择类似Protobuf（https://code.google.com/p/protobuf/protobuf，Google提供的一个开源数据交互格式，其最大的特点是基于二进制，因此比传统的JSON格式要小得多）之类的二进制通讯协议或者自己实现通讯协议，对于传输的内容进行一定程度的加密，以增加黑客破解协议的难度。下图是我截获的淘宝客户端的通讯数据，可以看到其中的值都不能直观地猜出内容，所以这对于通讯协议有一定的保护作用。
16.2.3 验证应用内支付的凭证
iOS应用内支付(APP)是众多应用盈利的方式，先让用户免费试用或试玩，然后提供应用内支付来为愿意付费的用户提供更强大的功能，这种模式特别适合不习惯一开始就掏钱的中国用户。但是，由于国内“越狱”用户的比例比较大，所以我们也需要注意应用内支付环节中的安全问题。
简单来说，越狱后的手机由于没有沙盒作为保护，黑客可以对系统进行任意地修改，所以在支付过程中，苹果返回的已付款成功的凭证可能是伪造的。客户端拿到付款凭证后，还需要将凭证上传到自己的服务器上，进行二次验证，以保证凭证的真实性。
另外，我们发现越狱用户的手机，很可能被黑客用中间人攻击技术来劫持支付凭证。这对于黑客有什么好处呢？因为苹果为了保护用户的隐私，支付凭证中并步包含用户的任何账号信息，所以我们的应用和服务器无法知道这个凭证是谁买的，而只能知道这个凭证是真的还是假的，所以在验证凭证时，哪个账号发起了验证请求，我们就默认这个凭证是该账号拥有的。如果黑客将凭证截获，就可以伪装成真实用户来验证或者转手出售获利。
打个比方，这就类似于很多商场的购物卡，由于它们是不记名的，如果黑客将你买的购物卡偷窃然后去刷卡购物，商场是无法简单地区分出来的。
所以，对于应用内支付，开发者除了需要仔细地验证购买凭证外，也需要告知用户在越狱手机上进行支付的风险。
16.3 本地文件和数据安全
16.3.1 程序文件的安全
iOS应用大部分的逻辑都是在编译后的二进制文件中，但是由于近年来混合式(Hybrid)编程方式的兴起，很多应用的部分功能也采用内嵌Web浏览器的方式来实现。例如腾讯QQiOS客户端的内部，就有部分逻辑是用Web方式来实现的。由于iOS安装文件其实就是一个zip包，所以我们可以通过解压，看到包内的内容。下面是解开腾讯QQ客户端后，看到的qqapi.js文件的内容:
可以看到，这些文件都有着完整清晰的注释。通过分析这些javaScript文件，黑客可以轻松地知道其调用逻辑，在越狱手机上，还可以修改这些JavaScript代码，以达到到攻击的目的。
我也曾经尝试查看支付宝客户端中的彩票功能，通过分析，也可以找到其完整的、带着清晰注释的JavaScript代码，如下图所示。(注：支付宝现在已经对相应代码进行了加密)
通过将JavaScript源码进行混淆和加密，可以防止黑客轻易地阅读和篡改相关的逻辑，也可以防止自己的Web端与Native端的通讯协议泄漏。
16.3.2 本地数据安全
iOS应用的数据在本地通常保存在本地文件或本地数据库中。如果本地的数据未进行加密处理，很可能被黑客篡改。以下是一个名为LepsWorld3的游戏，打开它的本地文件，可以很容易地看到，它使用了一个名为ItempLifes的变量保存生命数，如下图所示。
于是我们就可以简单修改该值，达到修改游戏参数的目的。而在淘宝上，也可以找到许多以此挣钱的商家，如下图所示。
对于本地的重要数据，我们应该加密存储或者将其保存到keychain中，以保证其不被篡改。
16.4 源代码安全
通过file、class-dum、theos、otool等工具，黑客可以分析编译之后的二进制程序文件，不过相对于这些工具来说，IDA的威胁最大。
IDA（https://www.hex-rays.com/products/ida/）是一个收费的反编译工具，对于Objective-C代码，它常常可以反汇编到可以方便阅读的程序，这对于程序的安全性，也是一个很大的危害。因为通过阅读源码，黑客可以更加方便地分析出应用的通讯协议和数据加密方式。
下面分别示例了一段代码的原始内容，以及用过IDA反汇编之后的结果。可以看到，IDA几乎还原了原本的逻辑，而且可读性也非常强。
原始代码：
反汇编后：
获得反汇编的代码后，由于软件内部逻辑相对汇编代码来说可读性强了很多，黑客可以用来制作软件的注册机，也可以更加方便地破解网络通讯协议，从而制作出机器人(”僵尸“)账号。在最极端的情况下，黑客可以将反汇编的代码稍加修改，植入木马，然后重新打包发布在一些越狱渠道上，这将对用户产生巨大的危害。
对于IDA这类工具，我们的应对措施就比较少了。除了可以用一些宏来简单混淆类名外，我们也可以将关键的逻辑用纯C实现。例如微信的iOS端的通讯底层，就是用C实现的。这样的方式除了能保证通讯协议安全外，也可以在iOS和Android等多个平台使用同一套底层通讯代码，达到复用的目的。
16.5 总结
由于移动互联网的快速发展，人们的购物、理财等的需求也在移动端出现，这使得移动应用安全性越来越重要。由于部署在用户终端上，移动应用比服务器应用更容易被攻击，大家也需要在移动应用的网络通讯、本地文件和数据、源代码三方面做好防范，只有这样才能保证应用的安全。