iOS 開發安全那些事兒

? 隨著移動互聯網的普及，被越來越多的心懷不軌的人覬覦，也越來越多的安全問題暴露了出來。開發者開發出來的應用被安裝在設備上之后，用戶并不具有專業的安全知識。因此，開發者有義務為用戶的安全保駕護航，能夠為用戶提供可信賴的服務才會被其青睞。

? 攻擊者在暗，我們在明，我們不知道對方會使用怎樣的方式威脅到應用的安全。因此我先就最壞的情況來考慮，即會有人惡意去逆向我們的應用，我們應該怎么樣去應對這些可能出現的危險。

常用的逆向分析手段

? 要知道怎么防備，我們就需要知道一些常用的逆向分析方式，這樣才能知己知彼。通常來說分析有三種手段：

• 靜態分析

  靜態分析這一階段主要會利用給各種工具，來幫助開發者分析目標軟件，常用的工具有比如Hopper、IDA、Keychain-Dumper、Class-dump等。

  其中IDA是效果最好也是最貴的，代碼還原度很高，基本上可以照著理清楚代碼的邏輯了。

• 動態分析

  動態分析是指在軟件運行的過程中進行調試分析。在iOS中runtime扮演了一個很重要的角色，我們在動態分析的過程中往往也是借助了runtime的強大能力來進行的，比如我們可以動態地更改代碼的行為、可以獲取到當前的視圖層次等等。這一部分我們可以利用的工具有包括Cycript、Reveal、LLDB等。

• 網絡分析

  流量分析是指利用像Charles這樣的抓包分析工具，分析應用的流量信息，安全意識比較差的公司做的一些產品我們往往能從中得到一些敏感信息。

  ?

如何防？

? 攻擊者往往會從以上這幾個點去查找你的應用中可能存在的漏洞，一旦找到了他們的切入點，下一步相對來說會簡單一點。在接下來的內容中，針對以上幾點圍繞著二進制安全、數據安全以及網絡安全來講述。

二進制安全

? 攻擊者會拿到我們的應用進行分析，然后可能會篡改我們的執行文件或者是資源文件，因此我們有必要采用一些手段來防止他們窺探以及對應用的行為進行修改：

• 防止調試器依附

  通常黑客可能會通過gdb或者lldb來調試我們的應用以驗證代碼的行為，為后一步攻擊做準備。而調試器之所以能夠工作是因為 Ptrace 的存在，它為調試器提供了監控目標進程的機會。因此，通常情況下，我們在應用中禁用掉它，這可以參考我之前寫的這篇文章以及github的 demo 。

• 越獄檢測

  當應用被安裝在一臺越獄后的設備之后，它所面臨的安全風險就會相對來說大很多。而可能處于安全性的考慮，可能我們并不希望我們的應用運行在這樣的環境下，因此我們可以通過一些檢測來判斷是否處在越獄的設備上。通常來說越獄設備上會安裝Cydia、MobileSubstrate等。我們可以在代碼中檢測Applications下是否有相關應用存在，如果存在就可以給用戶相應的提示并進行處理。

• 敏感字符串安全

  編譯之后的應用中對已經初始化的字符串依然是可見的，把應用丟到IDA或者Hopper中很容易就看到一些敏感字符串的值了。因此字符串的加密處理是很有必要的，比如我們可以用一些簡單的加密算法加密特別敏感的字符串，這樣初始化出來的字符串是一串不可讀的問題，需要使用的時候再進行解密。

• 混淆

  這一步主要是為了迷惑敵人的視線，提升分析難度。編譯的時候可以通過腳本加入無意義的代碼以及將正常的字符串替換為無意義的代碼。但是這樣的方式會給自己在維護的時候帶來一定困難，比如你的代碼通過混淆后發生了crash，通過dsym符號表解析出來的崩潰信息也變得不可讀了，還得對照混淆時候的映射表來查看，所以需要三思這個到底值不值得做。

  除此之外，我們還可以混淆文件名。前幾天想逆向看看滴滴的模塊化是如何做的，無意發現了一張很有意思的圖片，后綴表示是一個圖片，但是實際上是個存有字符串的文件。我們可以用類似的方式偽裝一些相對重要的文件。

• 敏感業務用更安全的語言

  OC是一門具有動態特性的語言，這給了攻擊者很多機會去修改你原有代碼的行為，甚至是加上新的代碼。因此在核心部分可以使用更加安全的代碼，比如我們可以使用C甚至匯編去寫。往簡單來說用Swift來寫代碼都比OC一定程度上來得安全。

• 自檢

  我們可以對二進制文件或者資源文件進行md5，然后交給我們的server去比對是否來自一個合法的應用，這一定程度上也能夠提供一些防護性。

數據安全

? 我們的應用可能會在本地存儲一系列的文件，包括用戶數據，數據庫文件，甚至在日益興起的Hybrid開發或者是各種Patch方式中我們會下載的源碼文件。我們應該盡可能地確保這些文件不會輕易被竊取到，即使竊取到了之后黑客也沒辦法使用。

• 數據保護

  我們需要將類似用戶密碼這樣的敏感數據存到keychain中。我們還會在本地存儲多種類型的文件，其中可能會包含一些敏感信息。我們在使用的時候是可以設置其訪問安全限制的。比如下面在使用FileManager的時候使用 FileProtectionType.complete 用以保證文件只有在設備未被鎖定時才可訪問。同樣在使用Keychain的時候也有類似的做法。

try? FileManager.default.setAttributes([.protectionKey: FileProtectionType.complete], ofItemAtPath: "your path ")

• 數據擦除

  有些敏感數據我們希望用完就把它給干掉，不留一點痕跡。比如用戶在輸入密碼進行登錄的時候，我們的viewModel上有一個叫做password的property。登錄完成之后，我們即使把這個屬性置為空之后值都依然在內存當中，這個時候我們可能需要手動地把這些敏感內容給擦掉。

• 防止鍵盤緩存

  鍵盤的自動更正機制會緩存用戶的輸入，如果在一臺越獄設備上的話很可能被第三方應用輕易地讀取到緩存中的數據。

  簡單來說我們可以把UITextfield的autocorrectionType屬性設置為No來關掉這個功能。在一些安全性要求較高的應用當中通常會自定義鍵盤，這樣可以防止緩存被第三方應用讀取到也能夠防止被錄屏（系統鍵盤按下有效果）。

網絡安全

• 不傳輸明文

  我們不應該在網絡中明文傳輸敏感數據。否則即使在沒越獄的手機上，很容易遭到中間人攻擊，黑客可以輕而易舉地獲取到用戶的敏感數據。

• 使用https

  蘋果本來準備強制要求的，不知道為何擱淺了，重要性不言而喻。

• 使用更安全的協議

  比如我們可以使用二進制協議或者是自定義協議來提高安全性。

• Hybrid應用安全

  如今React Native、Cordova等應用得越來越廣，安全性也變得越來越重要。

  在這樣的開發中，Mobile扮演的角色就是一個瀏覽器，因此在前端開發中常用的防護手段也在此使用，比如JS代碼混淆、XSS防護、加密傳輸等。

  ?

非惡意攻擊造成的安全問題

? 以上大部分都是一些比較惡意的針對終端用戶的攻擊防護，所謂防君子不防小人，想要搞破壞的人總是會找到辦法的。我們也還應該注意一些無意之間容易造成的安全問題。

• 應用退到后臺

蘋果會在應用退到后臺的時候進行截屏，會將當戶當前的狀態截圖保存下來，這可能會在無意之中造成用戶數據的泄漏，因此我們可能需要主動地替換掉這張截圖。

• 警惕iCloud備份

  用戶在開啟iCloud的情況下，可能會自動對文件目錄進行自動備份，我們需要指定包含敏感信息的文件不能進行備份。

• 注意Touch ID的變化

  自從iPhone有Touch ID之后大大的方便了用戶的使用，比如我們可以按一個手指就進行支付、登錄等操作。我們在開發這樣的業務邏輯的時候，應該考慮到這樣的場景，會不會因為一些正常情況下手機借給朋友造成了信息或者財產的流逝。

• 防止類似XcodeGhost事件再次發生

  早前發生的XcodeGhost事件掀起了一陣波瀾，讓我們意識到，即使是非越獄設備上也可能由于疏忽造成一些安全問題，因此我們需要警惕類似的事件再次發生。

總結：

? 道高一尺魔高一丈，如果終端不在用戶手中，總是能夠見招拆招的。作為開發工程師的我們雖然不需要具備很強的安全能力，但是我們需要了解一些基礎的知識并具有一定的安全意識，盡可能地為我們的產品和用戶負責。

來自：http://www.jianshu.com/p/31f53d63c3f1