您好,登錄后才能下訂單哦!
本篇內(nèi)容主要講解“iOS開發(fā)怎樣避免安全隱患”,感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷,實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“iOS開發(fā)怎樣避免安全隱患”吧!
一、網(wǎng)絡(luò)方面
用抓包工具可以抓取手機(jī)通信接口的數(shù)據(jù)。以Charles為例,用Charles可以獲取http的所有明文數(shù)據(jù),配置好它的證書后就可以模擬中間人攻擊,獲取https加密前的明文數(shù)據(jù)。
1.1 中間人攻擊
先簡(jiǎn)要地說(shuō)下什么是中間人攻擊:
①客戶端:“我是客戶端,給我你的公鑰” -> 服務(wù)端(被中間人截獲)。
所以現(xiàn)在是:
客戶端->中間人
②然后中間人把消息轉(zhuǎn)給服務(wù)端,也就是:
中間人->服務(wù)端
③服務(wù)端把帶有公鑰的信息發(fā)送給客戶端,但是被中間截獲。所以是:
服務(wù)端-[服務(wù)端的公鑰] ->中間人
④中間人把服務(wù)端的公鑰替換成自己的公鑰,發(fā)送給客戶端,聲稱是服務(wù)端的公鑰:
中間人-[中間人的公鑰] ->客戶端
⑤客戶端用得到的公鑰加密,實(shí)際是用中間人的公鑰進(jìn)行加密,所以中間人可以用自己的私鑰解密,獲取原始數(shù)據(jù),然后再用服務(wù)端的公鑰對(duì)原始數(shù)據(jù)(或者修改原始數(shù)據(jù)內(nèi)容)加密后發(fā)送給服務(wù)端。
這樣中間人就可以獲取到雙方的通信數(shù)據(jù),并可以制造虛假數(shù)據(jù)。
1.2 如何防范中間人攻擊?
下面開始說(shuō)如何防范:
1.2.1 SSL Pinning
SSL Pinning的原理就是把服務(wù)端的公鑰存到客戶端中,客戶端會(huì)校驗(yàn)服務(wù)端返回的證書是否和客戶端保存的一致,這樣就避免了中間人替換證書進(jìn)行的攻擊。
SSL Pinning的實(shí)現(xiàn)比較簡(jiǎn)單,只需要把CA證書放入項(xiàng)目中,通過(guò)Security framework實(shí)現(xiàn)NSURLSession上的SSL Pinning。如果用的是AFNetworking,代碼更簡(jiǎn)單一點(diǎn):
這樣通過(guò)Charles抓包就會(huì)報(bào)錯(cuò)。
證書驗(yàn)證有可以只驗(yàn)證公鑰(AFSSLPinningModePublicKey),也可以完全驗(yàn)證證書(AFSSLPinningModeCertificate)。
但是用SSL Pinning有個(gè)很嚴(yán)重的問(wèn)題,就是如果證書有問(wèn)題,只有發(fā)布新版本才能解決。如果新版本一直審核不通過(guò),app的網(wǎng)絡(luò)通信就全部掛掉了。
比如賽門鐵克(Symantec)證書被google和iOS12不信任的問(wèn)題。如果app內(nèi)置了證書,就必須要重新發(fā)版。
1.2.2 接口內(nèi)容進(jìn)行加密
很多的app接口只對(duì)請(qǐng)求的參數(shù)進(jìn)行加密和各種驗(yàn)證,而接口返回過(guò)來(lái)的數(shù)據(jù)就是明文。如果不用SSL Pinning來(lái)防止中間人攻擊,也可以把接口返回的數(shù)據(jù)也進(jìn)行加密,這樣抓包工具抓到包后也依然不能破解。
比如微信,微信中的接口用的是http協(xié)議,但是內(nèi)容全部進(jìn)行了加密。
現(xiàn)在常用的是對(duì)稱加密,加密效率比較快。如果app里有的數(shù)據(jù)特別重要,還是要用非對(duì)稱加密,非對(duì)稱加密更安全,但是效率會(huì)比較慢。
二、日志
2.1 Swift日志
Swift中打印日志的語(yǔ)法可以用print,也可以用NSLog。但是盡量別用NSLog,因?yàn)镾wift中用NSLog,系統(tǒng)日志中是能查到的??梢酝ㄟ^(guò)pp助手、iTools或者Xcode的Devices and Simulators 來(lái)查看系統(tǒng)日志。
用print打印日志就不會(huì)出現(xiàn)在系統(tǒng)日志中。
2.2 OC日志
在release環(huán)境下不要輸出NSLog日志。一般大家都會(huì)用宏定義解決,如下:
三、信息的存儲(chǔ)
3.1 密鑰
大部分的程序員喜歡直接把密鑰放到宏或者常量里。
如:#define AES_KEY @“aaa123"
這樣做很容易就可以被反編譯出來(lái)。安全性比較差。可以用以下方法加強(qiáng)安全,增加破解的難度。
對(duì)密鑰(A)進(jìn)行加密后定義為宏(B),使用的時(shí)候進(jìn)行解密得到密鑰(A)。其中對(duì)密鑰A加密的密鑰為C。
因?yàn)樵诤甓x的時(shí)候我們?nèi)绻x成字符串,會(huì)直接存在data段,這樣破解者很容易獲取到。比較安全的做法是把C和B定義成uint8_t[]數(shù)組,這樣每個(gè)字符就會(huì)放到text段的每個(gè)單獨(dú)指令中。指令執(zhí)行后生成字符串。這樣就會(huì)很安全。
用一段長(zhǎng)文本,按規(guī)則提取出里面的密鑰,密鑰是隨機(jī)的。
在服務(wù)端和客戶端定義一段長(zhǎng)文本,app端隨機(jī)生成起始位置和長(zhǎng)度,把起始位置和長(zhǎng)度進(jìn)行移位等操作,生成相應(yīng)的數(shù)字,對(duì)數(shù)字進(jìn)行Base64編碼,生成的字符串 傳給服務(wù)端,服務(wù)端根據(jù)這個(gè)字符串 就能 解析出相關(guān)的密鑰。
代碼如下:
這樣只是增加了破解者獲取密鑰的難度,其實(shí)并不能完全阻止破解者獲取。
3.2 Keychain
越獄的iPhone可以查看導(dǎo)出Keychain保存的信息。Keychains的內(nèi)容存放在sqlite中,目錄為:/private/var/Keychains??梢酝ㄟ^(guò)keychain-dump可以查看鑰匙串里存放的的內(nèi)容。
所以保存到Keychain的數(shù)據(jù)一定要是加密之后的數(shù)據(jù)。
3.3 plist、sqlite
plist、sqlite可以直接在ipa安裝文件中獲取到,所以不要在這些文件中存放重要信息,如果要保存,就進(jìn)行加密后再存放。
四、app加固
4.1 代碼混淆
代碼混淆就是把易讀的類名、方法名替換成不易讀的名字。常用的方法有宏替換和腳本替換。
比如本來(lái)方法名為:- (void)loadNetData; 進(jìn)行代碼混淆后,用class-dump導(dǎo)出頭文件后會(huì)顯示成修改后的方法名:- (void)showxhevaluatess;
4.2 用C語(yǔ)言
核心代碼用C語(yǔ)言寫,但是C語(yǔ)言的函數(shù)也可以被hook,比如用fishhook。開發(fā)人員可以用靜態(tài)內(nèi)聯(lián)函數(shù)來(lái)防止hock,破解者就只能去理解代碼的邏輯。
4.3 檢測(cè)tweak
可以檢測(cè) /Library/MobileSubstrate/DynamicLibraries 下的 plist 文件里是否包含自己app的bundle id。如果包含,可以進(jìn)行限制app的功能、提示該手機(jī)不安全 等。
到此,相信大家對(duì)“iOS開發(fā)怎樣避免安全隱患”有了更深的了解,不妨來(lái)實(shí)際操作一番吧!這里是億速云網(wǎng)站,更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢,關(guān)注我們,繼續(xù)學(xué)習(xí)!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。