虽说，APPLE的iOS是封闭的，每个app有着沙盒路径，发布途径也只有唯一的APPStore, 但是，危险遍布于开发的各个阶段，同时对安全的重视程度也间接提现了一个开发者的能力和意识。这里只是做一个总结，会一步步完善，将开发过程中涉及到和安全相关的问题都记录下来，作为积累。
相对来说，APP端的安全主要是和网络的数据传输、本地数据存储这2个方面。
（之前著名的xcode鬼 事件，属于另外板块的问题，暂且不表）
网络请求的安全方案：
1. HTTPS
1.1
其实HTTPS从最终的数据解析的角度，与HTTP没有任何的区别，HTTPS就是将HTTP协议数据包放到SSL/TSL层加密后，在TCP/IP层组成IP数据报去传输，以此保证传输数据的安全；而对于接收端，在SSL/TSL将接收的数据包解密之后，将数据传给HTTP协议层，就是普通的HTTP数据。HTTP和SSL/TSL都处于OSI模型的应用层。从HTTP切换到HTTPS是一个非常简单的过程
首先用这个是因为http的数据是裸露的（举个例子，之前微信朋友圈很火的红包看图功能，我们直接抓包，就可以看到图片url，就能查看原图，何必再去专门发个红包😄 -- 当然不差钱的童鞋除外）。 所以用https，一定程度上降低了传输速率（其实损耗并不大的），但是SSL/TSL层加密之后，加上证书的限制，可以解决50%的安全隐患。
1.2
具体怎么用，上代码:
(这是AFNetworking的代码，如果你的app网络请求没有用这个，那官方API在这里)：
NSURL * url = [NSURL URLWithString:@"https://www.google.com"];
AFHTTPRequestOperationManager * requestOperationManager = [[AFHTTPRequestOperationManager alloc] initWithBaseURL:url];
dispatch_queue_t requestQueue = dispatch_create_serial_queue_for_name("kRequestCompletionQueue");
requestOperationManager.completionQueue = requestQueue;
AFSecurityPolicy * securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];
//allowInvalidCertificates 是否允许无效证书（也就是自建的证书），默认为NO
//如果是需要验证自建证书，需要设置为YES
securityPolicy.allowInvalidCertificates = YES;
//validatesDomainName 是否需要验证域名，默认为YES；
//假如证书的域名与你请求的域名不一致，需把该项设置为NO
//主要用于这种情况：客户端请求的是子域名，而证书上的是另外一个域名。因为SSL证书上的域名是独立的，假如证书上注册的域名是www.google.com，那么mail.google.com是无法验证通过的；当然，有钱可以注册通配符的域名*.google.com，但这个还是比较贵的。
securityPolicy.validatesDomainName = NO;
//validatesCertificateChain 是否验证整个证书链，默认为YES
//设置为YES，会将服务器返回的Trust Object上的证书链与本地导入的证书进行对比，这就意味着，假如你的证书链是这样的：
//GeoTrust Global CA
// Google Internet Authority G2
// *.google.com
//那么，除了导入*.google.com之外，还需要导入证书链上所有的CA证书（GeoTrust Global CA, Google Internet Authority G2）；
//如是自建证书的时候，可以设置为YES，增强安全性；假如是信任的CA所签发的证书，则建议关闭该验证；
securityPolicy.validatesCertificateChain = NO;
requestOperationManager.securityPolicy = securityPolicy;
1.3
其他杂项
iOS9和OSX 10.11 开发时,Xcode的Info.plist的NSAppTransportSecurity详细设置方法请参考Apple官方文档:NSAppTransportSecurity Reference
|
[我是来打脸的]
大部分公司，不差钱会直接自己购买CA证书（当然，这样也更安全）。部分小公司可能会自己做证书（其实即使买了证书，也还是很容易被伪证书欺骗）。
最直观的方式是，我们做成一个类VPN的APP（也叫中间人攻击），我们负责截获目标APP的发送/响应的数据包，伪造CA证书或者伪证书的方式通过验证。
这种https遭遇攻击的例子数不胜数,虽然多半是Android的
a>.乌云的报告
b>.Android证书信任问题
2. 请求加校验值
这个我们自己做的时候会在请求header里面打一个hashVerify的值，
这个值由我们自己组装，按照一定的格式，然后做加密（一般是MD5，当然也可以用其他加密方式）
服务端拿到我的请求后，首先会验证这个hashVerify，如果这个值校验错误，则不通过。
扩展：
这个值加盐值， 加盐的目的是防止彩虹破解。
比如我们之前的请求按照格式拼接出来的字符串是abcde，然后加盐值polen，然后用abcdepolen做md5加密，这样，如果第三方不知道polen这个值，就没法破解我们的请求hashVerify值。
再扩展：
当然，再格式化hashVerify的时候，再加上设备号，加上当前时间戳，这些具有唯一性的参数，可大大增加安全性。
这样可以防止暴力破解或者爬虫。
比如一个设备在10min内，高频访问某个请求，这都可以限制住（当然，限制的逻辑要放在server做）
[我是来打脸的]
