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

標籤：

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

過去兩年，研究人員已發現Android上的流行軟體普遍存在安全缺陷或安全性漏洞。漏洞頻發的原因可能有很多，例如以下幾種。

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

• Team Dev通常將精力集中在產品設計、功能實現、使用者體驗和系統效率等方面，而很少考慮安全問題。

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

• 一方面，目前很少出現對特定移動軟體安全性漏洞的大規模針對性攻擊，在真實的攻擊出現之前，許多人對此並不重視。另一方面，利用這些漏洞展開攻擊並不太難，許 多攻擊方法和工具都已經成熟。一旦出現這種攻擊，使用者的個人隱私資料可能發生泄漏，賬戶資訊可能被盜取，如果與釣魚等攻擊結合，甚至可能產生經濟損失。產 品Team Dev則可能由此面臨信任危機和法律風險。

我在此前進行的一些安全評估中，看到不少Team Dev已具有非常高的安全開發水平，但也發現有知 名企業的軟體存在各種缺陷。在本文中，我們將向大家介紹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。

密碼和認證策略

明文儲存和編碼儲存密碼

許多軟體有“記住密碼”的功能。如果開發人員依字面含義將密碼儲存到本地，可能導致泄漏。

另 外，有的軟體不是直接儲存密碼，而是用Base64、固定位元組或字串異或、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殊途同歸。

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