雖說，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內，高頻訪問某個請求，這都可以限制?。ó斎唬拗频倪壿嬕旁趕erver做）
[我是來打臉的]
