原文地址：http://android.xsoftlab.net/training/articles/security-tips.html

Android系統(tǒng)內(nèi)置的安全策略可以有效的降低應(yīng)用程序的安全問題。所以默認(rèn)創(chuàng)建的應(yīng)用程序已經(jīng)包含了一定程度的安全保護(hù)措施。

Android所包含的安全策略有：

• 應(yīng)用程序沙箱，它可以使APP的數(shù)據(jù)、代碼與其它APP相互隔離。
• 應(yīng)用程序框架對(duì)于常見防護(hù)措施的強(qiáng)大實(shí)現(xiàn)，比如密碼、權(quán)限以及安全的IPC機(jī)制。
• 一些安全技術(shù)的應(yīng)用，比如ASLR, NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD calloc, 以及Linux mmap_min_addr，可以降低常見的內(nèi)存管理錯(cuò)誤風(fēng)險(xiǎn)。
• 文件加密系統(tǒng)可以保證設(shè)備在丟失后其中的數(shù)據(jù)不被盜取。
• 用戶權(quán)限授予可以限制訪問系統(tǒng)特性以及用戶數(shù)據(jù)。
• Android定義的權(quán)限可以控制程序的數(shù)據(jù)只能在程序的控制范圍之內(nèi)。

本文中所提及的Android安全策略對(duì)于日常開發(fā)非常重要，應(yīng)養(yǎng)成良好的編碼習(xí)慣。在日常的編碼行為中使用以下策略可以有效降低無意中造成的安全風(fēng)險(xiǎn)。

數(shù)據(jù)存儲(chǔ)

應(yīng)用程序常見的安全問題就是它們的數(shù)據(jù)是否可被其它應(yīng)用程序訪問到。Android有3種基本的數(shù)據(jù)存儲(chǔ)方式。

內(nèi)部存儲(chǔ)

默認(rèn)情況下，由APP自己創(chuàng)建的文件只能由APP本身訪問。這種防護(hù)措施由Android框架實(shí)現(xiàn)，也足以應(yīng)對(duì)大多數(shù)應(yīng)用的安全情況。

通常應(yīng)當(dāng)避免為IPC文件使用MODE_WORLD_WRITEABLE模式或MODE_WORLD_READABLE模式，因?yàn)檫@些模式?jīng)]有對(duì)數(shù)據(jù)的訪問提供限制能力，也沒有在數(shù)據(jù)格式上做任何控制。如果需要在進(jìn)程間共享數(shù)據(jù)，你應(yīng)當(dāng)考慮使用ContentProvider。ContentProvider對(duì)APP提供了數(shù)據(jù)讀寫權(quán)限，也可以按照實(shí)際情況動(dòng)態(tài)的授予權(quán)限。

如果需要對(duì)一些較為敏感的數(shù)據(jù)提供額外的保護(hù)，你可以使用密鑰對(duì)本地文件進(jìn)行加密。比如，可以將密鑰放入KeyStore，并以用戶密碼將其保護(hù)起來。不過這種方案也不是萬能的：某些破解手段可以監(jiān)視用戶所輸入的密碼，不過這種方式可以對(duì)丟失的設(shè)備進(jìn)行保護(hù)。

外部存儲(chǔ)

在外部存儲(chǔ)器上創(chuàng)建的文件可被全局讀寫。因?yàn)橥獠看鎯?chǔ)器可被用戶移除，也可以被任何的應(yīng)用程序修改，所以不應(yīng)當(dāng)在外部存儲(chǔ)器上存儲(chǔ)敏感的用戶數(shù)據(jù)。

正因?yàn)榭赡艽嬖诓豢尚刨Y源，所以從外部存儲(chǔ)器中讀取數(shù)據(jù)時(shí)應(yīng)當(dāng)執(zhí)行輸入驗(yàn)證。我們強(qiáng)烈的建議不要在外部存儲(chǔ)器上存儲(chǔ)用于動(dòng)態(tài)加載的可執(zhí)行文件或者類文件。如果APP需要從外部存儲(chǔ)器上接收可執(zhí)行文件，那么這些文件應(yīng)當(dāng)是被簽過名的，在加載之前也應(yīng)當(dāng)對(duì)這些簽名進(jìn)行校驗(yàn)。

內(nèi)容提供者

ContentProvider提供了一種結(jié)構(gòu)化的存儲(chǔ)機(jī)制，這種機(jī)制可以對(duì)所有的應(yīng)用程序形成一種約束。如果不打算使其它的應(yīng)用程序訪問你的ContentProvider，那么只需在程序的清單文件中標(biāo)記ContentProvider的屬性android:exported=false即可。否則，設(shè)置android:exported=true便意味著其它應(yīng)用程序可以訪問其中的數(shù)據(jù)。

在創(chuàng)建ContentProvider時(shí)默認(rèn)允許其它應(yīng)用程序可以訪問其中的數(shù)據(jù)，你可以對(duì)讀或者寫進(jìn)行單一權(quán)限限制，也可以同時(shí)管理。

如果使用ContentProvider只是為了在自身的APP之間共享數(shù)據(jù)，更加合理的方式是將android:protectionLevel屬性值設(shè)置為”signature”。Signature權(quán)限不需要用戶確認(rèn)，所以這樣可以提供良好的用戶體驗(yàn)，以及更多的控制力。

ContentProvider還可以通過android:grantUriPermissions屬性提供更細(xì)粒度的訪問能力。訪問者應(yīng)當(dāng)在Intent中使用FLAG_GRANT_READ_URI_PERMISSION標(biāo)志或FLAG_GRANT_WRITE_URI_PERMISSION標(biāo)志進(jìn)行訪問。這些權(quán)限的范圍可被做更進(jìn)一步的限制。

當(dāng)訪問ContentProvider時(shí)，使用參數(shù)化方法比如query(), update(), 及delete()可以避免不可信來源的SQL注入。

不要對(duì)寫入權(quán)限的安全擁有錯(cuò)誤的認(rèn)知。考慮一下，寫入權(quán)限允許執(zhí)行SQL語句，這可能會(huì)使一些數(shù)據(jù)被確認(rèn)。比如，一名攻擊者可能會(huì)在通話記錄中查找一個(gè)指定的電話號(hào)碼是否存在，如果這條數(shù)據(jù)存在，那么攻擊者只需進(jìn)行修改便可得知結(jié)果。如果ContentProvider的數(shù)據(jù)結(jié)構(gòu)可被猜測(cè)出，那么寫入權(quán)限就相當(dāng)于也同時(shí)提供了讀取權(quán)限。

使用權(quán)限

因?yàn)锳ndroid每個(gè)應(yīng)用都處于沙箱之內(nèi)，所以如果需要共享資源與數(shù)據(jù)的話，應(yīng)用必須顯式的聲明自有權(quán)限。

請(qǐng)求權(quán)限

我們推薦應(yīng)用程序所需的權(quán)限越少越好。這樣可以降低權(quán)限濫用的風(fēng)險(xiǎn)，也更易讓用戶接受，也可以減少黑客的攻擊入口。通常情況下，如果某個(gè)權(quán)限不是必要的，那就不要去請(qǐng)求它。

如果應(yīng)用程序可以做到不需要任何權(quán)限，那么這是最完美的。比如，如果需要通過訪問設(shè)備信息的方式來創(chuàng)建唯一標(biāo)識(shí)符的話，我們更推薦GUID。又比如，相比于將數(shù)據(jù)存儲(chǔ)于外部存儲(chǔ)器，我們更推薦內(nèi)部存儲(chǔ)器。

另外在請(qǐng)求權(quán)限時(shí)，可以使用< permissions>來保護(hù)IPC。IPC對(duì)于安全特別敏感、薄弱，并且它會(huì)被暴露給其它應(yīng)用程序，比如ContentProvider。 除了可能需要用戶確認(rèn)的權(quán)限之外，我們更推薦使用訪問控制，因?yàn)檫@些權(quán)限可能會(huì)使用戶感到困惑、不解。比如，可以考慮對(duì)個(gè)人開發(fā)者的應(yīng)用程序使用”signature“的IPC權(quán)限保護(hù)等級(jí)。

不要泄露受保護(hù)的權(quán)限數(shù)據(jù)。這種情況僅會(huì)發(fā)生在通過IPC共享數(shù)據(jù)時(shí)：因?yàn)樗鼡碛刑厥獾臋?quán)限，并且對(duì)于任何的IPC接口的客戶端也沒有要求出示該權(quán)限。

More details on the potential impacts, and frequency of this type of problem is provided in this research paper published at USENIX:http://www.cs.berkeley.edu/~afelt/felt_usenixsec2011.pdf

創(chuàng)建權(quán)限

通常情況下應(yīng)當(dāng)盡量少的使用權(quán)限，少用權(quán)限就意味著更安全。創(chuàng)建權(quán)限這種事情對(duì)于大多數(shù)應(yīng)用來說是用不到的，因?yàn)橄到y(tǒng)定義的權(quán)限足以涵蓋所有情況，這些權(quán)限會(huì)提供訪問檢查。

如果必須創(chuàng)建權(quán)限，考慮是否可以使用”signature”保護(hù)等級(jí)完成你的所需任務(wù)。”signature”會(huì)將自身完全暴露給用戶，只允許具有相同簽名的應(yīng)用程序訪問。

如果要?jiǎng)?chuàng)建”dangerous”保護(hù)等級(jí)的權(quán)限，那么有些東西需要考慮在內(nèi)：

• 權(quán)限必須提供一段簡(jiǎn)短的描述該權(quán)限安全的字符串。
• 描述權(quán)限的字符串必須提供不同地區(qū)的語言。
• 如果權(quán)限的描述含糊不清或者用戶認(rèn)為這會(huì)為其帶來風(fēng)險(xiǎn)，那么用戶可能會(huì)選擇不安裝應(yīng)用。
• 如果權(quán)限的生成器沒有安裝的話，應(yīng)用程序可能會(huì)請(qǐng)求權(quán)限。

上面的每一條對(duì)于作為程序員的你都是一項(xiàng)重要的非技術(shù)性挑戰(zhàn)，這樣做可能會(huì)使用戶感到困惑，這就是為什么我們不鼓勵(lì)使用”dangerous”權(quán)限等級(jí)的原因。

網(wǎng)絡(luò)安全

網(wǎng)絡(luò)傳輸本身就存在安全風(fēng)險(xiǎn)，因?yàn)樗鼤?huì)包括用戶的隱私數(shù)據(jù)。人們?cè)絹碓疥P(guān)心移動(dòng)設(shè)備的隱私問題，尤其是執(zhí)行網(wǎng)絡(luò)傳輸時(shí)，所以APP需要至始至終以最佳的安全方案保護(hù)用戶的數(shù)據(jù)安全。

使用IP網(wǎng)絡(luò)

Android所處的網(wǎng)絡(luò)環(huán)境與其它的Linux系統(tǒng)有著很大的不同。主要考慮的就是選用適用于敏感數(shù)據(jù)傳輸?shù)膮f(xié)議。比如HttpsURLConnection用于安全的WEB通信。我們推薦在支持HTTPS，因?yàn)橐苿?dòng)設(shè)備會(huì)頻繁的連接到不可信網(wǎng)絡(luò)，比如公共的Wi-Fi熱點(diǎn)。

經(jīng)認(rèn)證，Socket等級(jí)的加密通訊可以使用SSLSocket類簡(jiǎn)單實(shí)現(xiàn)。鑒于Android設(shè)備會(huì)頻繁的連接到不安全的無線網(wǎng)絡(luò)，所以我們強(qiáng)力的建議對(duì)所有的應(yīng)用程序都使用安全的網(wǎng)絡(luò)實(shí)現(xiàn)。

我們也見過一些應(yīng)用在處理敏感的IPC上使用了localhost網(wǎng)絡(luò)端口。我們不鼓勵(lì)使用這種方式，因?yàn)檫@些接口能被其它應(yīng)用程序訪問到，應(yīng)當(dāng)使用Android的IPC機(jī)制。

還有一個(gè)常見的問題就是，根證書重復(fù)用于驗(yàn)證從HTTP或者其它網(wǎng)絡(luò)上下載的不可信數(shù)據(jù)。這也包括WebView以及HTTP請(qǐng)求響應(yīng)的輸入驗(yàn)證。

使用電話網(wǎng)絡(luò)

SMS(短消息服務(wù))協(xié)議主要用于個(gè)人對(duì)個(gè)人之間的通訊，它并不適用于APP的數(shù)據(jù)傳輸。由于SMS的限制，我們強(qiáng)烈的推薦使用Google Cloud Messaging(GCM)及IP網(wǎng)絡(luò)來傳輸服務(wù)器與設(shè)備之間的數(shù)據(jù)。

要注意，SMS既沒有對(duì)網(wǎng)絡(luò)和設(shè)備進(jìn)行加密也沒有對(duì)其進(jìn)行相關(guān)驗(yàn)證。尤其是，任何的SMS接收器應(yīng)當(dāng)考慮到會(huì)有一位惡意的用戶會(huì)發(fā)送SMS給你的應(yīng)用，不要相信沒有驗(yàn)證過的SMS數(shù)據(jù)，并用它們來執(zhí)行一些敏感操作。還有，你應(yīng)當(dāng)意識(shí)到SMS可能會(huì)在網(wǎng)絡(luò)上被攔截并被篡改。在Android設(shè)備內(nèi)，SMS消息是由廣播意圖傳送的，所以這些數(shù)據(jù)可以被擁有READ_SMS權(quán)限的應(yīng)用程序讀取到。

輸入驗(yàn)證

無論程序運(yùn)行在哪個(gè)平臺(tái)上，沒有執(zhí)行充分的輸入驗(yàn)證都是影響程序安全的主要原因之一。Android提供了平臺(tái)等級(jí)的安全策略，這可以降低應(yīng)用程序輸入驗(yàn)證問題的暴露率，應(yīng)用程序應(yīng)當(dāng)盡可能的使用這些平臺(tái)特性。還應(yīng)該注意：安全性語言的選擇傾向于減少輸入驗(yàn)證問題的可能性。

如果你在使用本地代碼，那么從文件中讀取的數(shù)據(jù)、從網(wǎng)絡(luò)上接收的數(shù)據(jù)或從IPC接收的數(shù)據(jù)都可能會(huì)引起安全問題。最常見的問題就是緩沖區(qū)溢出，使用釋放后的對(duì)象等等。Android提供了大量的相關(guān)技術(shù)手段比如ASLR(Address Space Layout Randomization)、DEP(Data Execution Prevention)，這些技術(shù)手段可以降低這些錯(cuò)誤的出現(xiàn)頻率，但是它們不會(huì)解決根本的內(nèi)在問題。你可以謹(jǐn)慎的處理指針或管理緩沖區(qū)來防止這些問題的出現(xiàn)。

如果使用SQL數(shù)據(jù)庫(kù)或者ContentProvider進(jìn)行數(shù)據(jù)查詢，那么SQL注入可能是個(gè)問題。避免這些問題最好使用參數(shù)化的查詢方法。將權(quán)限降為只讀或只寫可以降低SQL注入帶來的相關(guān)風(fēng)險(xiǎn)。

如果不能夠使用以上提及的安全建議，那么我們強(qiáng)烈推薦使用結(jié)構(gòu)良好的數(shù)據(jù)格式，并在使用時(shí)對(duì)這些數(shù)據(jù)格式進(jìn)行驗(yàn)證。

處理用戶數(shù)據(jù)

通常來說，對(duì)于用戶的數(shù)據(jù)安全最好的方法就是盡量少使用可以訪問到敏感數(shù)據(jù)或者用戶數(shù)據(jù)的API。如果可以避免存儲(chǔ)或者傳輸這些信息，那么就不要傳輸這些數(shù)據(jù)?？煽紤]應(yīng)用程序是否能夠?qū)崿F(xiàn)這么一種邏輯：使用數(shù)據(jù)的哈希碼或者一種不可逆的數(shù)據(jù)形態(tài)。比如，程序可能會(huì)實(shí)現(xiàn)這么一種邏輯：將電子郵件地址的哈希碼作為一個(gè)關(guān)鍵的值，這樣可以避免使用原有的電子郵件地址，這可以降低暴露數(shù)據(jù)的機(jī)會(huì)，也可以降低攻擊者入侵應(yīng)用程序的機(jī)會(huì)。

如果程序需要訪問用戶的個(gè)人信息，比如密碼或者用戶名等等，要記住一些組件可能會(huì)要求你提供相關(guān)的隱私政策，來解釋這些數(shù)據(jù)的使用與存儲(chǔ)。所以接下來數(shù)據(jù)訪問實(shí)踐可以簡(jiǎn)化遵循規(guī)則。

你還應(yīng)當(dāng)考慮應(yīng)用程序是否有無意中將用戶的個(gè)人數(shù)據(jù)暴露給了第三方。如果你不清楚這些第三方組件或服務(wù)為什么要使用用戶的信息，那么就不要提供給它們。通常降低個(gè)人信息的訪問可以降低這塊的安全風(fēng)險(xiǎn)。

如果必須要訪問敏感數(shù)據(jù)，那么評(píng)估一下這些信息是否有必要傳輸?shù)椒?wù)器，或者是否這些操作只需在客戶端執(zhí)行就可以?？紤]凡是涉及到用戶敏感數(shù)據(jù)的代碼都在客戶端執(zhí)行，這樣可以避免不必要的網(wǎng)絡(luò)傳輸和安全泄漏問題。

還有，要確保沒有將用戶數(shù)據(jù)通過IPC、全局可讀寫文件或者網(wǎng)絡(luò)Socket暴露給其它應(yīng)用程序。

如果需要GUID，可以創(chuàng)建一個(gè)大的唯一的數(shù)據(jù)將其保存下來。不要使用與電話有關(guān)的數(shù)字，比如電話號(hào)碼、IMEI，這些信息可能會(huì)與用戶信息有關(guān)。

寫入設(shè)備日志時(shí)要當(dāng)心。在Android中，日志是共享資源，可被具有READ_LOGS權(quán)限的應(yīng)用讀取到。盡管日志數(shù)據(jù)是臨時(shí)的，但是不恰當(dāng)?shù)挠脩粜畔⑷罩究赡軙?huì)無意中將信息泄露給其它應(yīng)用程序。

WebView的使用

因?yàn)閃ebView會(huì)解析像HTML和JavaScript這樣的web內(nèi)容，所以不正確的使用會(huì)帶來常見的安全隱患。Android提供了大量機(jī)制來收縮這些潛在問題的范圍，比如通過限制WebView的能力來達(dá)到最低的運(yùn)行需求。

如果程序沒有直接使用到WebView中的JavaScript，那么不要調(diào)用setJavaScriptEnabled()。一些示例代碼可能會(huì)使用該方法，所以如果不需要的話，在你的程序中關(guān)閉它。默認(rèn)情況下，WebView不會(huì)執(zhí)行JavaScript，所以不會(huì)發(fā)生跨站腳本攻擊。

使用addJavaScriptInterface()需要特別當(dāng)心，因?yàn)樗鼤?huì)允許JavaScript調(diào)用預(yù)留給Android原生應(yīng)用的方法。如果你使用它，要確認(rèn)所有的Web的相關(guān)內(nèi)容都是可信的。如果不可信的內(nèi)容允許進(jìn)入，那么不可信的 JavaScript 可能會(huì)調(diào)用App內(nèi)的相關(guān)方法。一般我們推薦在APK內(nèi)包含JavaScript代碼的時(shí)候使用addJavaScriptInterface()。

如果程序通過WebView訪問敏感數(shù)據(jù)，你可能需要使用clearCache()方法來刪除存儲(chǔ)在本地的所有文件。我們可以使用HTTP頭部的某些屬性比如no-cache來表示應(yīng)用程序不應(yīng)當(dāng)緩存某些特殊的內(nèi)容。

Android 4.4之前版本的webkit含有大量的安全問題。如果App運(yùn)行在這些版本上，應(yīng)當(dāng)確認(rèn)WebView所渲染的內(nèi)容都是可信的。如果應(yīng)用必須渲染開放的Web內(nèi)容，考慮實(shí)現(xiàn)一個(gè)獨(dú)有的渲染器，這樣可以及時(shí)更新相關(guān)的安全補(bǔ)丁。

管理證書

通常來說，我們不推薦頻繁的要求用戶憑證，推薦使用授權(quán)令牌。

用戶名及密碼通常不應(yīng)該存在本地。應(yīng)當(dāng)使用用戶輸入的用戶名及密碼進(jìn)行初始化驗(yàn)證，然后使用一個(gè)權(quán)限Token進(jìn)行通信。

如果一個(gè)賬戶需要被多個(gè)程序訪問，那么應(yīng)當(dāng)使用AccountManager。如果可能的話，使用AccountManager與服務(wù)進(jìn)行交互，絕不要將密碼存在設(shè)備上。

如果證書只是用作于你創(chuàng)建的應(yīng)用程序，那么可以使用checkSignature()方法進(jìn)行程序訪問驗(yàn)證。如果只有一個(gè)程序使用了證書，那么KeyStore可能更適合你。

使用密碼

除了數(shù)據(jù)隔離、文件系統(tǒng)加密、安全通信通道等保護(hù)手段之外，Android還提供了一系列通過算法加密的安全保護(hù)措施。

通常情況下，Android內(nèi)置的最高等級(jí)的安全實(shí)現(xiàn)已經(jīng)可以支持各種安全情況。如果需要從一個(gè)已知的位置接受一個(gè)文件，那么HTTPS URI已經(jīng)足夠。如果需要一條安全通道，考慮使用HttpsURLConnection或SSLSocket。

如果發(fā)現(xiàn)確實(shí)需要實(shí)現(xiàn)自己的安全協(xié)議，不建議自己實(shí)現(xiàn)加密算法。而應(yīng)當(dāng)使用已有的加密算法比如在Cipher中提供的AES加密算法或RSA加密算法。

使用安全隨機(jī)數(shù)生成器SecureRandom來初始化密鑰KeyGenerator。如果不使用由SecureRandom生成的密鑰的話，則會(huì)大大減弱加密算法的健壯性，也更容易遭受線下攻擊。

如果需要將密鑰存在本地以便后續(xù)使用，那么可以使用KeyStore類似的加密機(jī)制。

使用進(jìn)程間通信

一些App嘗試使用傳統(tǒng)的Linux技術(shù)比如網(wǎng)絡(luò)Socket和共享文件來實(shí)現(xiàn)IPC。我們對(duì)此推薦使用Android為IPC實(shí)現(xiàn)的系統(tǒng)功能，例如Intent，Binder，Messenger和BroadcastReceiver。Android的IPC機(jī)制允許驗(yàn)證連接到你IPC的程序的身份，并且可以對(duì)每個(gè)IPC機(jī)制設(shè)置安全策略。

許多安全元素通過IPC機(jī)制共享。如果你的IPC機(jī)制的目的不是為了供其他應(yīng)用程序使用，那么請(qǐng)將對(duì)應(yīng)元素的android:exported的屬性設(shè)置為false。這對(duì)于由相同UID的多進(jìn)程組成的應(yīng)用很有幫助，或者對(duì)后期再開啟該功能也有一定的幫助。

如果IPC的目的是為了可被其他應(yīng)用訪問，你可以通過使用< permission>元素指定安全策略。如果IPC只是為了在持有相同key的兩個(gè)自有應(yīng)用中使用，那么android:protectionLevel=”signature”則更為適合。

使用Intent

Intent是異步IPC的首選機(jī)制。這取決于程序的需求，你可能會(huì)使用sendBroadcast(), sendOrderedBroadcast()或者顯式Intent來指定應(yīng)用程序組件。

要注意，由于有序廣播可以被接收方消耗掉，所以這些廣播可能不會(huì)被分發(fā)給所有的應(yīng)用程序。如果你發(fā)送了一個(gè)廣播，而該廣播必須被指定接收器接收的，那么必須使用顯式Intent，并且該Intent還需指明廣播接收器的名稱。

發(fā)送Intent的一方可以驗(yàn)證接收方是否允許非空的權(quán)限方法調(diào)用。只有含有該權(quán)限的應(yīng)用才會(huì)接收到該Inetnt。如果廣播中的Intent的數(shù)據(jù)是敏感的，那么應(yīng)當(dāng)考慮這里所使用的權(quán)限不會(huì)被非法的應(yīng)用程序攔截。在這種情況下，你應(yīng)當(dāng)考慮直接調(diào)用接收器，而不是使用廣播。

**Note:**Intent filters不應(yīng)當(dāng)被視作為一種安全特性：因?yàn)榻M件可能會(huì)由顯式的Intent調(diào)起。你應(yīng)當(dāng)在收到Intent的地方執(zhí)行輸入驗(yàn)證來確認(rèn)該Intent是否被格式化為適用于調(diào)用廣播接收器，服務(wù)或者Activity的格式。

使用服務(wù)

Service經(jīng)常被用作支持其他程序的功能。每個(gè)Service必須在它的清單文件中有相應(yīng)的聲明。

默認(rèn)情況下，Service不是開放的，也不能夠被其它應(yīng)用程序調(diào)起。然而，如果在Service的聲明中添加了IntentFilter，那么默認(rèn)就會(huì)被暴露出去。最好的辦法就是顯式的聲明android:exported屬性為你需要的屬性。Service還可以由android:permission屬性保護(hù)。如果這么做了，那么其它的程序則需要在它們的清單文件中聲明對(duì)應(yīng)的權(quán)限才可以啟動(dòng)、停止或者綁定該服務(wù)。

Service還可以保護(hù)在其權(quán)限內(nèi)的IPC調(diào)用，在執(zhí)行這個(gè)調(diào)用的實(shí)現(xiàn)之前調(diào)用checkCallingPermission()進(jìn)行必要檢查。我們通常推薦使用在清單文件中聲明的權(quán)限，因?yàn)橛泻芏嗦┒磿?huì)被忽略。

使用Binder及Messenger接口

Binder、Messenger是遠(yuǎn)程過程調(diào)用的首要IPC機(jī)制。它們提供了一種定義良好的接口：可以進(jìn)行端對(duì)端相互認(rèn)證。

我們強(qiáng)烈推薦以不需要特定的權(quán)限檢查的方式設(shè)計(jì)接口。由于Binder、Messenger并不是在應(yīng)用的清單文件中聲明過的，因此不能對(duì)其采用特定權(quán)限。它們的權(quán)限通常來自于對(duì)應(yīng)的Service或Activity所聲明的權(quán)限。如果你創(chuàng)建了一個(gè)用于請(qǐng)求驗(yàn)證或者訪問控制器的接口，那么這些控制器必須顯式的添加在Binder、Messenger的接口中。

如果創(chuàng)建了一個(gè)需要訪問控制器的接口，使用checkCallingPermission()驗(yàn)證調(diào)用者是否含有所需的權(quán)限。這在訪問服務(wù)的遠(yuǎn)端代理之前尤其重要，正如你的應(yīng)用的身份需要傳給其它接口一樣。如果調(diào)用一個(gè)由Service提供的接口，那么如果你沒有訪問給定服務(wù)所需的權(quán)限，那么bindService()的調(diào)用可能會(huì)失敗。如果調(diào)用一個(gè)由自身APP提供的一個(gè)本地的接口，那么clearCallingIdentity()則可以滿足內(nèi)部安全檢查的需求。

有關(guān)更多執(zhí)行與服務(wù)有關(guān)的IPC的相關(guān)信息，請(qǐng)參見Bound Services。

使用廣播接收器

BroadcastReceiver用于處理由Intent發(fā)起的異步請(qǐng)求。

默認(rèn)情況下，接收器可以被任何應(yīng)用調(diào)起。如果你的廣播接收器的作用是給其它程序使用，那么可能需要對(duì)接收器采取一些安全措施：在清單文件中添加相應(yīng)的安全權(quán)限。這可以防止沒有正確權(quán)限的應(yīng)用程序發(fā)送Intent給廣播接收器。

動(dòng)態(tài)加載代碼

Dalvik是Android的運(yùn)行時(shí)虛擬機(jī)。雖然Dalvik專用于Android，但是其它虛擬機(jī)上的相關(guān)安全問題也同樣適用于Android。一般不需要關(guān)心與虛擬機(jī)相關(guān)的安全問題，因?yàn)锳ndroid的應(yīng)用程序運(yùn)行在安全的沙箱環(huán)境中，所以系統(tǒng)上的其它進(jìn)程訪問不到程序的代碼或者私有數(shù)據(jù)。

如果你對(duì)更深的虛擬機(jī)安全課題感興趣，那么推薦熟悉一些現(xiàn)有的有關(guān)這一課題的相關(guān)文獻(xiàn)。其中最受歡迎的兩個(gè)資源如下：
- http://www.securingjava.com/toc.html
- https://www.owasp.org/index.php/Java_Security_Resources

這篇文檔主要關(guān)注于Android的特殊之處和與其它虛擬機(jī)環(huán)境有什么不同。對(duì)于對(duì)其它虛擬機(jī)很有經(jīng)驗(yàn)的開發(fā)者來說，這里有兩個(gè)很主要的Android的不同之處：

• 一些虛擬機(jī)，比如JVM或.net運(yùn)行時(shí)，扮演了一個(gè)安全邊界的角色，從底層操作系統(tǒng)將代碼、功能隔離。然而在Android中Dalvik虛擬機(jī)并沒有這樣的功能——應(yīng)用程序沙箱實(shí)現(xiàn)與操作系統(tǒng)層面，所以Dalvik可以與應(yīng)用的本地代碼進(jìn)行交互，而沒有任何的安全限制。
• 由于移動(dòng)設(shè)備有限的存儲(chǔ)空間，一些開發(fā)者可能需要通過模塊化構(gòu)建應(yīng)用程序，并使用動(dòng)態(tài)加載技術(shù)。如果這么做，那么則需要考慮在哪接收應(yīng)用的邏輯代碼？又應(yīng)當(dāng)將這些代碼存在哪？不要使用沒有經(jīng)過驗(yàn)證的代碼，比如從不安全的網(wǎng)絡(luò)資源上或者是外部存儲(chǔ)器中加載的代碼，因?yàn)檫@些代碼很有可能會(huì)被其它程序篡改。

本地代碼的安全

一般我們推薦使用Android SDK來進(jìn)行應(yīng)用程序開發(fā)，而不是使用本地代碼開發(fā)。由本地代碼構(gòu)建的程序會(huì)更加復(fù)雜，也缺少了靈活性，也更容易產(chǎn)生像緩沖區(qū)溢出等常見的內(nèi)存泄露錯(cuò)誤。

因?yàn)锳ndroid建立于Linux kernel基礎(chǔ)之上，所以如果使用本地代碼的話，那么Linux開發(fā)中所遇到的安全問題也同樣適用于此。由于Linux安全相關(guān)超出了本文的范圍，所以這里提供了很受歡迎的“Linux和Unix如何安全編程”的相關(guān)資源，相關(guān)地址：http://www.dwheeler.com/secure-programs.

Android與其它大部分Linux環(huán)境最大的不同就在于程序沙箱。在Android中，所有的程序都運(yùn)行在程序沙箱中，也包括那些本地代碼。在最基本的層面上，對(duì)熟悉Linux的開發(fā)者來說，不同之處就是Android的每個(gè)應(yīng)用程序都有一個(gè)唯一UID，也擁有少量的權(quán)限。如果要使用本地代碼開發(fā)的話，那么應(yīng)當(dāng)對(duì)應(yīng)用的權(quán)限極為了解才對(duì)。

PS: 翻譯的相關(guān)源文件皆已開源，開源地址：https://code.csdn.net/u011064099/android-training-chinese-version/tree/master，歡迎fork、star。

總結(jié)

以上是生活随笔為你收集整理的Android官方开发文档Training系列课程中文版：Android的安全建议的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。