iOS应用安全开发，你不知道的那些事

那篇文章不许转载，然后也并不知道我不经同意转载会不会拉我去坐牢，拉我去枪毙。

同时我也不想太麻烦到需要的时候又到处找，所以挂个链接在这吧！烦！

http://www.csdn.net/article/2014-04-30/2819573-The-Secret-Of-App-Dev-Security

http与https的安全与不安全问题探讨：
http://sanwen8.cn/p/1demKUd.html

截取一些关键点：

网络安全

1. 安全地传输用户密码

iOS应用在联网，通过与服务器端通信获取最新信息的时候，由于网络传输过程中有可能经过不安全的中间节点，所以应该对敏感数据加密，用于保证用户信息的安全。

尽量不要通过明文传输用户名，密码等，防止网络请求被抓包，泄露信息。

正确的做法应该是这样：事先生成一对用于加密的公私钥，客户端在登录时，使用公钥将用户的密码加密后，将密文传输到服务器。服务器使用私钥将密码解密，然后加盐（Salt，在密码学中是指，通过在密码任意固定位置插入特定的字符串，让散列后的结果和使用原始密码的散列结果不相符，这个过程称之为“加盐”），之后再多次求MD5，然后再和服务器原来存储的用同样方法处理过的密码匹配，如果一致，则登录成功。

这样的做法，保证黑客即使截获了加密后的密文，由于没有私钥，也无法还原出原始的密码。而服务器即使被黑客攻陷，黑客除了暴力尝试，也无法从加盐和多次MD5后的密码中还原出原始的密码。这样就保证了用户密码的安全。

2. 防止通信协议被轻易破解

开发者可以选择类似ProtoBuf（Google提供的一个开源数据交换格式，其最大的特点是基于二进制，因此比传统的JSON格式要短小得多）之类的二进制通信协议或自己实现通信协议，对于传输的内容进行一定程度的加密，以增加黑客破解协议的难度。

3. 验证应用内支付的凭证

越狱后的手机由于没有沙盒作为保护，黑客可以对系统进行任意地修改，所以在支付过程中，苹果返回的已付款成功的凭证可能是伪造的。客户端拿到付款凭证之后，还需要将凭证上传到自己的服务器上，进行二次验证，以保证凭证的真实性。

本地文件和数据安全

1. 程序文件的安全

iOS应用的大部分逻辑都是在编译后的二进制文件中，但由于近年来混合式（Hybrid）编程方式的兴起，很多应用的部分功能也采用内嵌Web浏览器的方式来实现。由于iOS安装文件其实就是一个zip包，所以我们可以通过解压，看到包内的内容。

通过将JavaScript源码进行混淆和加密，可以防止黑客轻易地阅读和篡改相关的逻辑，也可以防止自己的Web端与Native端的通信协议泄漏。

2.本地数据安全

iOS应用的数据在本地通常保存在本地文件或本地数据库中。如果对本地的数据不进行加密处理，很可能被黑客篡改。

对于本地的重要数据，我们应该加密存储或将其保存到keychain中，以保证其不被篡改。

源代码安全

通过file、class-dump、theos、otool等工具，黑客可以分析编译之后的二进制程序文件，不过相对于这些工具来说，IDA的威胁最大。IDA是一个收费的反汇编工具，对于Objective-C代码，它常常可以反汇编到可以方便阅读的程度，这对于程序的安全性，也是一个很大的危害。因为通过阅读源码，黑客可以更加方便地分析出应用的通信协议和数据加密方式。

反汇编的代码被获得后，由于软件内部逻辑相比汇编代码来说可读性高了很多。黑客可以用来制作软件的注册机，也可以更加方便地破解网络通信协议，从而制作出机器人（“僵尸”）账号。最极端的情况下，黑客可以将反汇编的代码稍加修改，植入木马，然后重新打包发布在一些越狱渠道上，这将对用户产生巨大的危害。

对于IDA这类工具，我们的应对措施就比较少了。除了可以用一些宏来简单混淆类名外，也可以将关键的逻辑用纯C语言来实现。例如微信的iOS端的通信底层，就是用C语言实现的。这样的方式除了能保证通信协议的安全外，也可以在iOS和Android等多个平台使用同一套底层通信代码，达到复用的目的。

---

---

目前，大部分的移动应用都是需要联网，与服务器进行通信，获取最新的数据。一提到网络，肯定就有大量和安全性相关的问题出来。所以，对于我们开发者而言，如何打造一个安全的App，是必须面对的问题。前段时间我专门对iOS移动应用安全性方面进行了研究，下面我们分析iOS应用中可能会存在的安全风险以及相对应的处理方式。

1、网络安全

在网络请求中，我们经常使用两种请求方式：GET和POST。如果是用GET发送请求，当我们采用明文的方式给服务器发送数据，数据里面还包含一些敏感数据如账号密码，这些数据都是包装在URL中，并且服务器的访问日志会记录，所以黑客一旦攻破服务器，可以轻易获得所有用户的账号密码。POST相对于GET来说，要相对安全一些，我们发给服务器的数据是包装在请求体中，不会直接暴露在url中。但是其实POST也是不安全的，在MAC电脑上可以利用Charles软件（如果在Windows下，可以使用Fiddler软件）来将自己的电脑设置成代理服务器，从而截取应用的网络请求，所以GET和POST都是不安全的。这时，为了防止账号密码泄漏，我们要对其进行加密。加密的方式有很多种，最简单的就是base64加密，但是base64 过于简单，很容易破解，不推荐使用。第二种就是md5加密，其核心思想是从给定的数据中提取特征码，不容产生重复，安全性比较高，在计算机安全领域使用的比较广泛，但是现在也有专门的网站对md5进行破解，为了使MD5加密更安全，我们会进行加盐，HMac，加时间戳等，提高安全级别和破解难度。第三种就是对称加密和非对称加密。非对称加密:事先生成一对用于加密的公私钥，客户端在登录时，使用公钥将用户的密码加密后，将密文传输到服务器。服务器使用私钥将密码解密。这样的做法，保证黑客即使截获了加密后的密文，由于没有私钥，也无法还原出原始的密码。

2、协议问题

iOS9.0 之前，做网络请求时时用http协议，但是http协议是不安全协议，很容易被攻破，在成功破解了通信协议后，黑客可以模拟客户端登录，进而伪造一些用户行为，可能对用户数据造成危害。像我们平常听到的游戏代练，刷分，其实是游戏的通信协议被破解，黑客制作出了代练的机器人程序。在iOS9.0后，苹果推荐采用https协议进行网络数据传输。当然，如果自己手上有更好更安全的协议，可以用自己的。

3、本地文件安全

iOS应用的数据在本地通常保存在本地文件或本地数据库中。如果对本地的数据不进行加密处理，很可能被黑客篡改，所以我们要对重要的数据进行加密，根据重要程度选择安全性可靠的方式。

4、源代码安全

应用程序上架需要编译成二进制文件，这些二进制文件也是存在安全隐患。黑客可以通知反编译工具，对这个文件进行反编译。对于Objective-C代码，它常常可以反汇编到可以方便阅读的程度，这对于程序的安全性，也是一个很大的危害。因为通过阅读源码，黑客可以更加方便地分析出应用的通信协议和数据加密方式。一般我们应对的方式给我们的代码加一些东西，混淆源代码的内容，比如定义一些乱其八糟的宏，比如打乱代码的顺序等。这样，就算文件被反编译成功，也需要花大量的时间去破解。

支持原创：http://blog.csdn.net/qq_34716474/article/details/51265092