Android軟件安全開發實踐（下）

Android開發是當前最火的話題之一，但不多有人討論這個領域的安全問題。本系列將分兩期，探討Android開發中常見的安全隱患和解決方案。第一期將從數據存儲、網絡通訊、密碼和認證策略這三個角度，帶你走上Android軟件安全開發實踐之旅。

過去兩年，研究人員已發現Android上的流行軟件廣泛存在安全缺陷或安全漏洞。漏洞頻發的緣由可能有不少，例如如下幾種。

• 與一切都是集中管理的iOS相比，Android提供了一種開放的環境，在得到了靈活性、能夠知足各類定製需求的同時，也損失了部分安全性。

• 開發團隊一般將精力集中在產品設計、功能實現、用戶體驗和系統效率等方面，而不多考慮安全問題。

• Android提供的安全機制比較複雜，開發者須要理解它們，並對常見的攻擊思路和攻擊方法有所瞭解，纔能有效地保護軟件。

• 一方面，目前不多出現對特定移動軟件安全漏洞的大規模針對性攻擊，在真實的攻擊出現以前，許多人對此並不重視。另外一方面，利用這些漏洞展開攻擊並不太難，許 多攻擊方法和工具都已經成熟。一旦出現這種攻擊，用戶的我的隱私數據可能發生泄漏，帳戶信息可能被盜取，若是與釣魚等攻擊結合，甚至可能產生經濟損失。產 品開發團隊則可能由此面臨信任危機和法律風險。

我在此前進行的一些安全評估中，看到很多開發團隊已具備很是高的安全開發水平，但也發現有知 名企業的軟件存在各類缺陷。在本文中，咱們將向你們介紹Android軟件中比較常見的安全缺陷或安全漏洞，分析產生問題的緣由，介紹可能的攻擊方法，並 給出解決問題的建議。但願能拋磚引玉，引發你們對這類問題的關注。

數據存儲

Android軟件可使用的存儲區域分爲外部（SD卡）和內部（NAND閃存）兩種。除了大小和位置不一樣以外，二者在安全權限上也有很大的區別。外部存儲的文件沒有讀寫權限的管理，全部應用軟件均可以隨意建立、讀取、修改、刪除位於外部存儲中的任何文件，而僅僅須要申明READ_EXTERNAL_STORAGE和READ_EXTERNAL_STORAGE權限。內部存儲則爲每一個軟件分配了私有區域，並有基於Linux的文件權限控制，其中每一個文件的全部者ID均爲Android爲該軟件設立的一個用戶ID。一般狀況下，其餘軟件無權讀寫這些文件。

關於數據存儲可能出現的問題包括如下幾種。

將隱私數據明文保存在外部存儲

例如，聊天軟件或社交軟件將聊天記錄、好友信息、社交信息等存儲在SD卡上；備份軟件將通訊錄、短信等備份到SD卡上等。若是這些數據是直接明文保存（包括 文本格式、XML格式、SQLite數據庫格式等）的，那麼攻擊者寫的軟件能夠將其讀取出來，並回傳至指定的服務器，形成隱私信息泄露。

較好的作法是對這些數據進行加密，密碼保存在內部存儲，由系統託管或者由用戶使用時輸入。

將系統數據明文保存在外部存儲

例如，備份軟件和系統輔助軟件可能將用戶已安裝的其餘軟件數據保存至SD卡，以便刷機或升級後進行恢復等；或者將一些系統數據緩存在SD卡上供後續使用。一樣的，若是這些數據是明文保存的，惡意軟件能夠讀取它們，有可能用於展開進一步的攻擊。

將軟件運行時依賴的數據保存在外部存儲

若是軟件將配置文件存儲在SD卡上，而後在運行期間讀取這些配置文件，並根據其中的數據決定如何工做，也可能產生問題。攻擊者編寫的軟件能夠修改這些配置文 件，從而控制這些軟件的運行。例如，若是將登陸使用的服務器列表存儲在SD卡中，修改後，登陸鏈接就會被髮往攻擊者指定的服務器，可能致使帳戶泄露或會話 劫持（中間人攻擊）。

對這種配置文件，較安全的方法是保存到內部存儲；若是必須存儲到SD卡，則應該在每次使用前判斷它是否被篡改，例如，與預先保存在內部的文件哈希值進行比較。

將軟件安裝包或者二進制代碼保存在外部存儲

如今不少軟件都推薦用戶下載並安裝其餘軟件；用戶點擊後，會聯網下載另外一個軟件的APK文件，保存到SD卡而後安裝。

也有一些軟件爲了實現功能擴展，選擇動態加載並執行二進制代碼。例如，下載包含了擴展功能的DEX文件或JAR文件，保存至SD卡，而後在軟件運行時，使用 dalvik.system.DexClassLoader類或者java.lang.ClassLoader類加載這些文件，再經過Java反射，執行 其中的代碼。

若是在安裝或加載前，軟件沒有對SD卡上的文件進行完整性驗證，判斷其是否可能被篡改或僞造，就可能出現安全問題。

在這裏，攻擊者可使用稱 爲「重打包」（re-packaging）的方法。目前大量Android惡意代碼已採用這一技術。重打包的基本原理是，將APK文件反彙編，獲得 Dalvik指令的smali語法表示；而後在其中添加、修改、刪除等一些指令序列，並適當改動Manifest文件；最後，將這些指令從新彙編並打包成 新的APK文件，再次簽名，就能夠給其餘手機安裝了。經過重打包，攻擊者能夠加入惡意代碼、改變軟件的數據或指令，而軟件原有功能和界面基本不會受到影 響，用戶難以察覺。

若是攻擊者對軟件要安裝的APK文件或要加載的DEX、JAR文件重打包，植入惡意代碼，或修改其原始代碼；而後在SD 卡上，用其替換原來的文件，或者拷貝到要執行或加載的路徑，當軟件沒有驗證這些文件的有效性時，就會運行攻擊者的代碼。攻擊結果有不少可能，例如直接發送 扣費短信，或者將用戶輸入的帳戶密碼發送給指定的服務器，或者彈出釣魚界面等。

所以，軟件應該在安裝或加載位於SD卡的任何文件以前，對其完整性作驗證，判斷其與實現保存在內部存儲中的（或從服務器下載來的）哈希值是否一致。

全局可讀寫的內部文件

若是開發者使用openFileOutput(String name,int mode)方法建立內部文件時，將第二個參數設置爲Context.MODE_WORLD_READABLE或 Context.MODE_WORLD_WRITEABLE，就會讓這個文件變爲全局可讀或全局可寫的。

開發者也許是爲了實現不一樣軟件之間的數據共享，但這種方法的問題在於沒法控制哪一個軟件能夠讀寫，因此攻擊者編寫的惡意軟件也擁有這一權限。

若是要跨應用共享數據，一種較好的方法是實現一個Content Provider組件，提供數據的讀寫接口，併爲讀寫操做分別設置一個自定義權限。

內部敏感文件被root權限軟件讀寫

若是攻擊者的軟件已得到root權限，天然能夠隨意讀寫其餘軟件的內部文件。這種狀況並很多見。

• 大量的第三方定製ROM提供了root權限管理工具，若是攻擊者構造的軟件僞形成一些功能強大的工具，能夠欺騙用戶授予它root權限。

• 即使手機安裝的官方系統，國內用戶也大多樂於解鎖、刷recovery並刷入root管理工具。

• 在Android 2.2和2.3中，存在一些能夠用於獲取root權限的漏洞，而且對這種漏洞的利用不須要用戶的確認。

所以，咱們並不能假設其餘軟件沒法獲取root權限。即使是存在內部的數據，依然有被讀取或修改的可能。

前面提到，重要、敏感、隱私的數據應使用內部存儲，如今又遇到root後這些數據依然可能被讀取的問題。我對這個問題的觀點是，若是攻擊者鋌而走險得到root權限（被用戶覺察或者被安全軟件發現的風險），那理論上他已擁有了系統的完整控制權，能夠直接得到聯繫人信息、短信記錄等。此時，攻擊者感興趣的 軟件漏洞利用更多是得到其餘由軟件管理的重要數據，例如帳戶密碼、會話憑證、帳戶數據等。例如，早期Google錢包將用戶的信用卡數據明文存儲，攻擊 者獲取這些數據後，能夠假裝成持卡人進行進一步攻擊以得到帳號使用權。這種數據就是「其餘由軟件管理的重要數據」。

這個問題並無通用的解決方法。開發者可能須要根據實際狀況尋找方案，並在可用性與安全性之間作出恰當的選擇。

網絡通訊

Android軟件一般使用WiFi網絡與服務器進行通訊。WiFi並不是老是可信的。例如，開放式網絡或弱加密網絡中，接入者能夠監聽網絡流量；攻擊者能夠本身設置WiFi網絡釣魚。此外，在得到root權限後，還能夠在Android系統中監聽網絡數據。

不加密地明文傳輸敏感數據

最危險的是直接使用HTTP協議登陸帳戶或交換數據。例如，攻擊者在本身設置的釣魚網絡中配置DNS服務器，將軟件要鏈接的服務器域名解析至攻擊者的另外一臺服務器；這臺服務器就能夠得到用戶登陸信息，或者充當客戶端與原服務器的中間人，轉發雙方數據。

早期，國外一些著名社交網站的Android客戶端的登陸會話沒有加密。後來出現了黑客工具FaceNiff，專門嗅探這些會話並進行劫持（它甚至支持在WEP、WPA、WPA2加密的WiFi網絡上展開攻擊！）。這是目前我所知的惟一一個公開攻擊移動軟件漏洞的案例。

這類問題的解決方法很顯然—對敏感數據採用基於SSL/TLS的HTTPS進行傳輸。

SSL通訊不檢查證書有效性

在SSL/TLS通訊中，客戶端經過數字證書判斷服務器是否可信，並採用證書中的公鑰與服務器進行加密通訊。

然而，有開發者在代碼中不檢查服務器證書的有效性，或選擇接受全部的證書。例如，開發者能夠本身實現一個X509TrustManager接口，將其中的 checkServerTrusted()方法實現爲空，即不檢查服務器是否可信；或者在SSLSocketFactory的實例中，經過 setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER)，接受全部證 書。作出這兩種選擇的可能緣由是，使用了本身生成了證書後，客戶端發現證書沒法與系統可信根CA造成信任鏈，出現了 CertificateException等異常。

這種作法可能致使的問題是中間人攻擊。

在釣魚WiFi網絡中，一樣地，攻 擊者能夠經過設置DNS服務器使客戶端與指定的服務器進行通訊。攻擊者在服務器上部署另外一個證書，在會話創建階段，客戶端會收到這張證書。若是客戶端忽略 這個證書的異常，或者接受這個證書，就會成功創建會話、開始加密通訊。但攻擊者擁有私鑰，所以能夠解密獲得客戶端發來數據的明文。攻擊者還能夠模擬客戶 端，與真正的服務器聯繫，充當中間人作監聽。

解決問題的一種方法是從可信CA申請一個證書。但在移動軟件開發中，不推薦這種方法。除了申請 證書的時間成本和經濟成本外，這種驗證只判斷了證書是否CA可信的，並無驗證服務器自己是否可信。例如，攻擊者能夠盜用其餘可信證書，或者盜取CA私鑰 爲本身頒發虛假證書，這樣的攻擊事件在過去兩年已有屢次出現。

事實上，移動軟件大多隻和固定的服務器通訊，所以能夠在代碼中更精確地直接驗 證是否某張特定的證書，這種方法稱爲「證書鎖定」（certificate pinning）。實現證書鎖定的方法有兩種：一種是前文提到的實現X509TrustManager接口，另外一種則是使用KeyStore。具體可參考 Android開發文檔中HttpsURLConnection類的概覽說明。

使用短信註冊帳戶或接收密碼

也有軟件使用短信進行通訊，例如自動發送短信來註冊、用短信接收初始密碼、用短信接收用戶重置的密碼等。

短 信並非一種安全的通訊方式。惡意軟件只要申明瞭SEND_SMS、RECEIVE_SMS和READ_SMS這些權限，就能夠經過系統提供的API向任 意號碼發送任意短信、接收指定號碼發來的短信並讀取其內容，甚至攔截短信。這些方法已在Android惡意代碼中廣泛使用，甚至2011年就已出現攔截並 回傳短信中的網銀登陸驗證碼（mTANs）的盜號木馬Zitmo。

所以，這種經過短信註冊或接收密碼的方法，可能引發假冒註冊、惡意密碼重置、密碼竊取等攻擊。此外，這種與手機號關聯的帳戶還可能產生增值服務，危險更大。較好的實現方式仍是走Internet。

密碼和認證策略

明文存儲和編碼存儲密碼

許多軟件有「記住密碼」的功能。若是開發者依字面含義將密碼存儲到本地，可能致使泄漏。

另 外，有的軟件不是直接保存密碼，而是用Base6四、固定字節或字符串異或、ProtoBuf等方法對密碼編碼，而後存儲在本地。這些編碼也不會增長密碼 的安全性。採用smali、dex2jar、jd-gui、IDA Pro等工具，攻擊者能夠對Android軟件進行反彙編和反編譯。攻擊者能夠藉此瞭解軟件對密碼的編碼方法和編碼參數。

較好的作法是，使用基於憑據而不是密碼的協議知足這種資源持久訪問的需求，例如OAuth。

對外服務的弱密碼或固定密碼

另外一種曾引發關注的問題是，部分軟件向外提供網絡服務，而不使用密碼或使用固定密碼。例如，系統輔助軟件常常在WiFi下開啓FTP服務。部分軟件對這個FTP服務不用密碼或者用固定密碼。在開放或釣魚的WiFi網絡下，攻擊者也能夠掃描到這個服務並直接訪問。

還有弱密碼的問題。例如，早期Google錢包的本地訪問密碼是4位數字，這個密碼的SHA256值被存儲在內部存儲中。4位數字一共只有10000種狀況，這樣攻擊軟件即使是在手機上直接暴力破解，均可以在短期內得到密碼。

使用IMEI或IMSI做爲惟一認證憑據

IMEI、IMSI是用於標識手機設備、手機卡的惟一編號。若是使用IMSI或IMEI做爲用戶認證的惟一憑據，可能致使假冒用戶的攻擊。

首先，應用要獲取手機的IMEI、手機卡的IMSI並不須要特殊權限。事實上，許多第三方廣告庫回傳它們用於用戶統計。其次，獲得IMEI或IMSI後，攻 擊者有多種方法僞形成用戶與服務器進行通訊。例如，將原軟件重打包，使其中獲取IMEI、IMSI的代碼始終返回指定的值；或修改Android代碼，使 相關API始終返回指定的值，編譯爲ROM在模擬器中運行；甚至能夠分析客戶端與服務器的通訊協議，直接模擬客戶端的網絡行爲。

所以，若使用IMEI或IMSI做爲認證的惟一憑據，攻擊者可能得到服務器中的用戶帳戶及數據。

 

咱們討論了數據存儲、網絡通訊、密碼和認證策略等安全問題和解決方案，本期將繼續從組件間通訊、數據驗證和保全保護等方面來實踐Android軟件安全開發之路。

組件間通訊

組件間通訊的安全問題是Android所獨有的，也是目前軟件中最常出現的一種問題。

咱們先回顧一下組件間通訊機制。Android有四類組件：activity、service、broadcast receiver和content provider。在同一個軟件之中或不一樣軟件之間，前三種組件使用Intent相互調用，使用ContentResolver對象訪問content provider，共同實現軟件的功能。使用Intent，能夠顯式或隱式地調用：

• 顯式（explicit）：調用者知道要調用誰，經過組件名指定具體的被調用者；

• 隱式（implicit）：調用者不知道要調用誰，只知道執行的動做，由系統選擇組件處理這個請求。

以下面的代碼所示：

不管是顯式仍是隱式，若是要跨應用調用，還須要被調用的組件是對外暴露的。默認狀況下，service、broadcast receiver和content provider是暴露的，申明瞭Intent-filter的actvity也是暴露的。

抽象地說，組件A要調用組件B，以期待B完成某個功能；它能夠發送一些數據給組件B，也能夠得到B執行後的返回結果。在這個模型中，問題出如今A和B之間不必定互相可信。

若是B是暴露的，任何軟件均可以調用它，包括攻擊者編寫的軟件。攻擊者可能但並不是總能成功：

• 直接調用暴露的B，以得到其執行結果；

• 構造特定的數據，並用於調用暴露的B，從而試圖影響B的執行；

• 調用暴露的B，並獲取它執行完返回的結果。

若是A用的是隱式調用，任何軟件均可以實現它的action從而響應調用。攻擊者可能（但並不是總能成功）：

• 構造僞造的組件C，響應A的Intent，以讀取A要發給B的數據；

• 構造僞造的組件C，響應A的Intent，彈出虛假的用戶界面以展開進一步攻擊（例如釣魚）；

• 構造僞造的組件C，響應A的Intent，返回僞造的執行結果。

這樣說可能比較抽象。下面咱們對這兩種狀況分別討論。

組件暴露的問題

看一個例子。在一個第三方深度定製的ROM中，預裝了名爲Cit.apk的軟件，用於手機的硬件測試。它的AndroidManifest.xml局部以下：

能夠看到，它申明一個名爲.CitBroadcastReceiver的receiver，響應名爲android.provider.Telephony.SECRET_CODE的action，而且指定了URI格式。

再來看這個receiver的代碼片斷（下面的代碼是我反編譯獲得的，不必定與軟件源碼徹底一致）：

能夠看到，當調用這個receiver，而且提供的URI中host字段爲284時，會以root權限調用本地的bugreport工具，並將結果輸出至m_logFileName指定的文件中。

默認狀況下receiver是暴露的，所以這個receiver能夠被其餘軟件調用，代碼以下：

當這四行代碼執行時，就會觸發CitBroadcast-Receiver的那段代碼。從上下文看，輸出文件m_logFileName位於SD卡，任何軟件均可以隨意讀寫。所以，攻擊者能夠得到bugreport的輸出結果，其中包含大量系統數據和用戶數據。

請注意，在這個例子中，攻擊者的軟件不須要任何特殊權限，尤爲是不須要root權限。這種因爲組件暴露得到額外權限的攻擊，被稱之爲permission re-delegation（權限重委派）。

怎麼避免因爲組件暴露產生的安全問題？有的組件必須暴露，例如入口activity，或者確實對外提供服務或跨軟件協做；但也有的組件不必暴露。接下來咱們分別討論。

不須要暴露的組件

再次回顧，默認狀況下，service、broadcast receiver和content provider是暴露的，申明瞭Intent-filter的actvity也是暴露的。若是它們只被同一個軟件中的代碼調用，應該設置爲不暴露。很容 易作到—在AndroidManifest.xml中爲這個組件加上屬性android:exported=」false」便可。

須要暴露的組件

若是組件須要對外暴露，應該經過自定義權限限制對它的調用。

首先，在實現了被調用組件的軟件的Android-Manifest.xml中自定義一個權限：

接下來，爲被調用組件添加這個權限限制，即在AndroidManifest.xml中爲這個組件添加android:permission屬性：

另外一種方法是在組件的實現代碼中使用Context.checkCallingPermission()檢查調用者是否擁有這個權限。

最後，要調用這個暴露的組件，調用者所在的軟件應該申明使用這個權限，即在AndroidManifest.xml中添加相應的use-permission申明。

進一步地，還能夠將這種組件暴露的需求分爲兩種狀況。

• 若是這個組件只打算給本身開發的其餘軟件使用，而不但願暴露給第三方軟件，在定義權限時，protectionLevel字段應該選擇signature。 這種設置要求權限使用者（即調用者）與權限定義者（即被調用者）必須由相同的證書進行簽名，所以第三方沒法使用該權限，也就沒法調用該組件。

• 若是這個組件要暴露給第三方，則protection-Level應使用normal或dangerous。此時，任何軟件均可以使用該權限，只在安裝時會 通知用戶。考慮到用戶通常會忽略權限提示，此時自定義權限實際失去了保護效果，咱們依然要仔細審查該組件的代碼，避免出現能力泄露或權限重委派等問題。

此外，對content provider，能夠更細粒度地爲讀取數據和寫入數據設置不一樣的權限，對應的manifest標籤分別爲android:readPermission和android:writePermission。

隱式調用的問題

隱式調用的主要問題是被劫持，或Intent攜帶的數據被讀取。

爲了劫持調用，攻擊者能夠實現一個惡意的組件，申明相同的Intent-filter。在多個組件均可以響應同一個Intent的狀況下，若是是調用 activity，系統會彈出界面要求用戶對多個軟件作出選擇，攻擊者能夠模仿真實軟件的圖標和名稱吸引用戶點擊；若是是調用service，系統會隨機 選擇一個service；若是是調用receiver，系統會逐一地將Intent發給這些receiver。

劫持了調用後，攻擊者能夠（但並不是總能成功）：

• 啓動一個虛假的軟件界面，展開釣魚攻擊（例如要求用戶輸入帳戶密碼）

• 讀取Intent攜帶的數據

• 攔截broadcast的進一步發送，致使真正的receiver沒法收到消息，從而拒絕服務

• 若是是用startActivityForResult()調用了虛假的activity，能夠返回惡意或虛假的結果給調用者

• 執行其餘惡意代碼

限於篇幅，對這些情形咱們不提供示例代碼。來看一下怎麼解決這類問題。

不須要隱式調用

除了基於Intent類中已有ACTIONs的隱式調用，絕大部分隱式調用都屬於這兩種狀況：同一軟件中不一樣組件的調用；同一開發者不一樣軟件間的調用。

這兩種狀況下，事實上，開發時都已能夠肯定要調用的組件是哪一個。所以能夠避免隱式調用，改成基於組件名的顯式調用。

須要隱式調用

發送broadcast除了使用sendBroadcast(Intent)，還有一個方法是sendBroadcast(Intent, String)，它的第二個參數能夠指定接受者須要的權限。

若是是調用activity或者service，目前我所知，尚未簡單的方法實現接收者的權限限制。在Android文檔中提出能夠自定義Binder和AIDL實現通訊雙方的互相驗證，但真正實現並不容易，也不爲官方所推薦。

數據驗證

不管是客戶端仍是服務器，在處理外部得到的數據以前，都應先判斷和驗證數據的有效性。這裏主要指是否包含畸形的數據。

在 Web開發中，服務器須要對用戶提交的數據進行有效性驗證，不然很容易出現衆所周知的SQL注入等攻擊。在移動開發中也不例外。雖然客戶端與服務器在底層 通訊協議上對用戶是透明、不可見的，但開發者不該所以就假設雙方傳輸的數據永遠會和預先設計的一致。相似的，在讀取用戶從UI元素輸入的輸入、讀取存儲在 本地的數據後，使用前也應進行有效性驗證。

軟件版權保護

攻擊者對Android軟件進行逆向分析，除了尋找其中的安全漏洞，還能夠直接攻擊軟件自己。

• 破解軟件的收費機制、License驗證或功能限制；

• 修改軟件代碼，去掉廣告庫，或者修改廣告庫（通常是改變推介ID字段），或者增長廣告庫，而後從新打包並分發；

• 從新打包，植入惡意代碼並分發；

• 逆向分析，學習軟件特點功能的實現方法，或者得到可複用的代碼；

能夠採起多種措施來增長破解、修改和逆向分析的難度，減小被攻擊的可能。這些措施包括：

• 使用代碼混淆工具，例如SDK帶的ProGuard以及其餘Java混淆器。

• 採用NDK開發核心模塊。

• 使用官方或第三方的軟件保護方案，例如SDK的android.drm包、Google Play的軟件許可（Application Licensing）支持。

• 去掉開發時的調試代碼，關閉調試開關，刪除多餘的Log代碼。

然而，採起了這些措施並不等於就萬無一失了。例如，用NDK開發的Native代碼，也可使用IDA Pro及其插件來反彙編、反編譯和調試；用Google的DRM方案，也有AntiLVL這樣的破解工具。理論上，現有防護手段均可能找到方法繼續攻擊， 其價值只是提升攻擊難度和成本。

總結

已出現和將要出現的威脅

到 目前爲止，在學術研究之外，針對Android軟件漏洞的攻擊只出現一塊兒—劫持國外多個社交網站客戶端登錄會話的黑客工具FaceNiff。但隨着攻擊者 製造傳播惡意代碼的成本增長和收益下降，以及移動終端隱私數據逐漸成爲地下產業鏈的交易資源，針對Android流行軟件漏洞的攻擊在將來幾年以內幾乎一 定會出現並爆發。

統一的安全模型

限於篇幅，本文只介紹了幾種常見且簡單的安全問題，還存在許多咱們知道的、還不知道的漏洞。如何找到和解決這些問題？

回顧已介紹的內容，咱們能夠發現它們有相似的安全模型：通訊雙方的信任問題。

• 在數據存儲中，讀寫數據的代碼和存儲在本地的數據互相不可信。

• 在數據通訊中，發送者和接受者互相不可信。

• 在登陸認證中，發起認證請求的用戶的和接受認證請求的服務器互相不可信。

• 在組件間通訊中，發起Intent的組件與接收Intent的組件互相不可信。

• 在數據驗證中，處理數據的模塊不能相信產生數據的源。

面對未來的問題，咱們也能夠嘗試抽象出這種模型，區分互相不可信的實體，而後在不可信、不安全的基礎上，儘量地實現相對的可信和安全。

進一步學習和行動

Android 的開發文檔Best Practices: Designing for Security和源碼文檔Tech Info: Security分別從開發和系統實現的角度介紹了系統的安全機制。另外，viaForensics提供了名爲42+ Best Practices: Secure mobile development for iOS and Android的在線教程，更詳細地介紹了移動軟件面臨的安全威脅，並給出了安全開發實踐策略。

社區方面，從Android安全開發的角 度，Stack-Overflow並不必定是很好的選擇—其中一些最佳回答沒有考慮安全，直接使用可能產生問題。Google Group的anroid-security-discuss討論組則更爲專業和準確。OWASP成立了一個Mobile Security工做組，目前已發佈Top Ten Mobile Risks等多份白皮書，並舉辦了AppSec會議。這個工做組的效率雖然不高，但產出質量很是棒。

學術方面，2011和2012年的四大會議及其work-shop上均有移動軟件漏洞挖掘和攻擊阻止的論文出現，從它們的related works部分能夠綜合快速地瞭解學術界的思路。

目前的移動開發尚未造成如此成熟的體系，這也許與其輕快敏捷的互聯網產品開發風格有關。但我相信，真正實效的移動軟件安全開發，最終依然會融合到需求分析、系統設計、開發實現、測試驗證、部署運維等每個環節，從而與PC平臺的SDL異曲同工。