前言：
高效讀書，一張邏輯圖讀懂、讀薄書中重點。
注：下面文字只是對邏輯思維圖的”翻譯“，節省時間，只看圖即可。

移動應用安全邏輯思維圖

?1.?? ?說明
1.1.?? ?互聯網公司的安全體系基本上以運維安全，應用安全，業務安全三管齊下。而移動應用安全則在應用安全中占據半壁江山，尤其對于移動端產品為主的公司而言，SDL的主要實踐對象就是移動應用
2.?? ?背景
2.1.?? ?隨著智能手機和其他移動設備的爆發式普及，移動應用已成為互聯網公司業務重要的業務方向。本章中會以移動兩大平臺之一的安卓為主線，介紹移動應用所面臨的安全風險和解決方案
3.?? ?業務架構分析
3.1.?? ?移動應用很少會單獨存在，多數情況下會作為互聯網業務流程中的承載平臺出現。如果業務同時存在傳統Web頁面服務模式，兩者從邏輯上處于并行的關系，只是不同的表現 ?
形式
3.2.?? ?作為一種運行在用戶控制設備上的應用，業務服務端應該假設客戶端提交的信息存在各種可能，在設計時需要關注哪些邏輯適合放在移動端，哪些邏輯需要保留在服務端
3.3.?? ?涉及業務核心數據的行為，例如游戲中的物品掉落，支付行為的判斷，賬號信息的更改等都需要在業務服務端進行判斷，而非客戶端
4.?? ?移動操作系統安全簡介
4.1.?? ?圖10-1是安卓系統的架構和安全相關的介紹可以參看https://source.android.com/security/index.html

4.1.1.?? ?硬件設備：安卓可運行在范圍廣泛的硬件上，并且支持某些硬件特有的安全功能， 例如 ARM v6 的 eXecute-Never 功能
4.1.2.?? ?安卓操作系統：底層為Linux內核，所有設備資源都通過該層提供，包括相機、GPS
數據、藍牙、電話、網絡等服務
4.1.3.?? ?安卓應用：通常使用Java開發，運行在Dalvik/ART虛擬機中，除此之外還包括一些二進制的組件。應用中不論是虛擬機還是二進制的部分都在相同的安全域，也就是該應用的沙盒中
4.2.?? ?現代移動操作系統和早期操作系統相比有一定的優勢，以Windows為例，在不斷更新的過程中，會被過去的理念和代碼實現所拖累。而安卓和iOS作為之后設計開發的操作系 統，在設計上加入了一些新的理念
5.?? ?簽名管理
5.1.?? ?為了確定應用的來源，無論安卓還是iOS都會對應用的簽名進行檢查，確保用戶安裝的應用來源可控
5.2.?? ?對于應用開發方，應該保護好本公司用于應用簽名的私鑰，推薦的解決方案是建立簽名服務器
5.3.?? ?在同一家公司內的應用推薦使用相同的簽名密鑰， 避免不同的應用使用不同的簽名，這樣不僅便于之后的發布和管理，在技術也便于之后可能存在的應用間通信需求
6.?? ?應用沙盒及權限
6.1.?? ?如之前所說，安卓和iOS作為之后設計開發的操作系統，在設計上加入了一些新的理念，其中重要的一點是通過沙盒(Sandbox)對各應用間的權限隔離，并在限定應用行為邊界后，通過按需申請應用權限的方式規范各應用的行為，這樣就將單個應用面臨的風險和其他應用以及操作系統相隔離
6.2.?? ?在安卓系統上，在接觸任何系統資源前，應用都要通過權限檢查，如圖10-2所示

6.3.?? ?如何實現沙盒
6.3.1.?? ?安卓和iOS內核都源自*nix類系統內核，對應用沙盒的技術實現都是基于操作系統提供的用戶機制。每個在系統上安裝的應用，如果沒有特殊設 定(SYSTEM或者安卓中SHARED-UID模式)，都會有系統分配給應用一個獨特的用戶ID (UID),單憑該UID,應用無法使用任何應用外的設備資源。只有當應用在安裝時預先申請了某些系統權限后，才會被準許進行權限對應的操作
7.?? ?應用安全風險分析
7.1.?? ?在應用和業務邏輯已經剝離的情況下，仍然可能存在嚴重的安全風險（接口和數據來源）
7.2.?? ?風險列表示例
7.2.1.?? ?應用間通信（IPC）:提供接口的組件權限，信息泄露，本地的數據加密和文件權限等，以安卓為例，IPC 接 口包括 Content Provider, Broadcast Receiver, Activity, Service 等形式
7.2.2.?? ?遠程數據：開放端口接收數據，接收的各類型文件，應用的自動升級，數據傳輸明文等
7.2.3.?? ?兩類目標：用戶：內容偽造，導致不能正確判斷，程序：代碼實現上的漏洞，代碼執行, 權限竊取和繞過。從嚴重程度來看，首先需要注意遠程來源數據
8.?? ?安全應對
8.1.?? ?對于三方的選擇，建議選取保持更新的開源項目，查看項目升級日志中修補過的安全列表，確認應用中將要使用的版本是否已經修補已知安全問題，并訂閱此項目的版本更新郵件，能在之后發布安全更新時第一時間評估影響
8.2.?? ?具體到自身代碼的引入的問題，需要符合最小化原則
8.2.1.?? ?對只需要應用自身使用到的組件，不提供給其他應用
8.2.2.?? ?對于不需要開放的端口，限定監聽在特定的IP
8.2.3.?? ?對于本地保存的數據庫或文件等，嚴格的限定讀寫權限等
8.2.4.?? ?在需要時提供完善的認證和加密機制
9.?? ?安全評估
9.1.?? ?代碼審計
9.1.1.?? ?iOS開發Xcode環境可使用整合的Clang Static Analyzer,而安卓Java代碼可以 使用FindBugs來完成代碼安全審計。具體審計范圍和使用可參考之后第II章“代碼審計”
9.2.?? ?應用加固
9.2.1.?? ?目前有一些在線的應用安全加固服務。用戶可上傳需要加固的應用，服務器接收應用后會從安全，逆向和調試難度等方面對應用進行評估，并按照用戶需要提供在這些方面完 成更改后的版本供下載
10.?? ?關于移動認證
10.1.?? ?為了方便用戶登錄認證，通常移動應用通過保存登錄信息或者加上簡單的本地認證方式（如手勢密碼或者數字PIN碼）來使用戶免于輸入完整的流程
10.2.?? ?以支付寶為例，限定數額以下的付款甚至不需要認證
10.2.1.?? ?這背后有很多需要背景數據收集，從第一次正常登錄時設備本身的信息，包括用戶日常操作行為收集的大數據等。在發現異常時，就會觸發完整的認證過程了
10.2.2.?? ?當然在攻擊者完全控制手機的情況，如果所有認證信息的要素都可以通過手機獲取到，例如保存的認證信息，動態認證短信等，更多能夠做到的也只有提高攻擊的成本，而不能完全避免認證信息的盜用

總結

以上是生活随笔為你收集整理的高质量解读《互联网企业安全高级指南》三部曲（技术篇）——移动应用安全的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。