Android 安全要點(diǎn)

編寫:craftsmanBai - http://z1ng.net - 原文:http://developer.android.com/training/articles/security-tips.html

Android內(nèi)建的安全機(jī)制可以顯著地減少了應(yīng)用程序的安全問題。你可以在默認(rèn)的系統(tǒng)設(shè)置和文件權(quán)限設(shè)置的環(huán)境下建立應(yīng)用，避免針對(duì)一堆頭疼的安全問題尋找解決方案。

一些幫助建立應(yīng)用的核心安全特性如下：

• Android應(yīng)用程序沙盒，將應(yīng)用數(shù)據(jù)和代碼的執(zhí)行與其他程序隔離。
• 具有魯棒性的常見安全功能的應(yīng)用框架，例如加密，權(quán)限控制，安全I(xiàn)PC
• 使用ASLR，NX，ProPolice，safe_iop，OpenBSD dlmalloc，OpenBSD calloc，Linux mmap_min_addr等技術(shù)，減少了常見內(nèi)存管理錯(cuò)誤。
• 加密文件系統(tǒng)可以保護(hù)丟失或被盜走的設(shè)備數(shù)據(jù)。
• 用戶權(quán)限控制限制訪問系統(tǒng)關(guān)鍵信息和用戶數(shù)據(jù)。
• 應(yīng)用程序權(quán)限以單個(gè)應(yīng)用為基礎(chǔ)控制其數(shù)據(jù)。

盡管如此，熟悉Android安全特性仍然很重要。遵守這些習(xí)慣并將其作為優(yōu)秀的代碼風(fēng)格，能夠減少無意間給用戶帶來的安全問題。

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

對(duì)于一個(gè)Android的應(yīng)用程序來說，最為常見的安全問題是存放在設(shè)備上的數(shù)據(jù)能否被其他應(yīng)用獲取。在設(shè)備上存放數(shù)據(jù)基本方式有三種:

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

默認(rèn)情況下，你在內(nèi)部存儲(chǔ)中創(chuàng)建的文件只有你的應(yīng)用可以訪問。Android實(shí)現(xiàn)了這種機(jī)制，并且對(duì)于大多數(shù)應(yīng)用程序都是有效的。 你應(yīng)該避免在IPC文件中使用MODE_WORLD_WRITEABLE或者MODE_WORLD_READABLE模式，因?yàn)樗鼈儾粸樘厥獬绦蛱峁┫拗茢?shù)據(jù)訪問的功能，它們也不對(duì)數(shù)據(jù)格式進(jìn)行任何控制。如果你想與其他應(yīng)用的進(jìn)程共享數(shù)據(jù)，可以使用Content Provider，它可以給其他應(yīng)用提供了可讀寫權(quán)限以及逐項(xiàng)動(dòng)態(tài)獲取權(quán)限。

如果想對(duì)敏感數(shù)據(jù)進(jìn)行特別保護(hù)，你可以使用應(yīng)用程序無法直接獲取的密鑰來加密本地文件。例如，密鑰可以存放在KeyStore而非設(shè)備上，使用用戶密碼進(jìn)行保護(hù)。盡管這種方式無法防止通過root權(quán)限查看用戶輸入的密碼，但是它可以為未進(jìn)行文件系統(tǒng)加密的丟失設(shè)備提供保護(hù)。

使用外部存儲(chǔ)

創(chuàng)建于外部存儲(chǔ)的文件，比如SD卡，是全局可讀寫的。 由于外部存儲(chǔ)器可被用戶移除并且能夠被任何應(yīng)用修改，因此不應(yīng)使用外部存儲(chǔ)保存應(yīng)用的敏感信息。 當(dāng)處理來自外部存儲(chǔ)的數(shù)據(jù)時(shí)，應(yīng)用程序應(yīng)該執(zhí)行輸入驗(yàn)證（參看輸入驗(yàn)證章節(jié)） 我們強(qiáng)烈建議應(yīng)用在動(dòng)態(tài)加載之前不要把可執(zhí)行文件或class文件存儲(chǔ)到外部存儲(chǔ)中。 如果一個(gè)應(yīng)用從外部存儲(chǔ)檢索可執(zhí)行文件，那么在動(dòng)態(tài)加載之前它們應(yīng)該進(jìn)行簽名與加密驗(yàn)證。

使用Content Providers

ContentProviders提供了一種結(jié)構(gòu)存儲(chǔ)機(jī)制，它可以限制你自己的應(yīng)用，也可以允許其他應(yīng)用程序進(jìn)行訪問。 如果你不打算向其他應(yīng)用提供訪問你的ContentProvider功能，那么在manifest中標(biāo)記他們?yōu)?a rel="external nofollow" target="_blank" target="_blank">android:exported=false即可。 要建立一個(gè)給其他應(yīng)用使用的ContentProvider，你可以為讀寫操作指定一個(gè)單一的permission，或者在manifest中為讀寫操作指定確切的權(quán)限。我們強(qiáng)烈建議你對(duì)要分配的權(quán)限進(jìn)行限制，僅滿足目前有的功能即可。 記住，通常新的權(quán)限在新功能加入的時(shí)候同時(shí)增加，會(huì)比把現(xiàn)有權(quán)限撤銷并打斷已經(jīng)存在的用戶更合理。

如果Content Provider僅在自己的應(yīng)用中共享數(shù)據(jù)，使用簽名級(jí)別android:protectionLevel的權(quán)限是更可取的。 簽名權(quán)限不需要用戶確認(rèn)，當(dāng)應(yīng)用使用同樣的密鑰獲取數(shù)據(jù)時(shí)，這提供了更好的用戶體驗(yàn)，也更好地控制了Content Provider數(shù)據(jù)的訪問。 Content Providers也可以通過聲明android:grantUriPermissions并在觸發(fā)組件的Intent對(duì)象中使用FLAG_GRANT_READ_URI_PERMISSION和FLAG_GRANT_WRITE_URI_PERMISSION標(biāo)志提供更細(xì)致的訪問。 這些許可的作用域可以通過grant-uri-permission進(jìn)一步限制。 當(dāng)訪問一個(gè)ContentProvider時(shí)，使用參數(shù)化的查詢方法，比如query()，update()和delete()來避免來自不信任源潛在的SQL注入。 注意，如果selection語句是在提交給方法之前先連接用戶數(shù)據(jù)的，使用參數(shù)化的方法或許不夠。 不要對(duì)“寫”權(quán)限有一個(gè)錯(cuò)誤的觀念。 考慮“寫”權(quán)限允許sql語句，它可以通過使用創(chuàng)造性的WHERE子句并且解析結(jié)果讓部分?jǐn)?shù)據(jù)的確認(rèn)變?yōu)榭赡堋?例如：入侵者可能在通話記錄中通過修改一條記錄來檢測(cè)某個(gè)特定存在的電話號(hào)碼，只要那個(gè)電話號(hào)碼已經(jīng)存在。 如果content provider數(shù)據(jù)有可預(yù)見的結(jié)構(gòu)，提供“寫”權(quán)限也許等同于同時(shí)提供了“讀寫”權(quán)限。

使用權(quán)限

因?yàn)榘沧可澈袑?yīng)用程序隔離，程序必須顯式地共享資源和數(shù)據(jù)。它們通過聲明他們需要的權(quán)限來獲取額外的功能，而基本的沙盒不提供這些功能，比如相機(jī)訪問設(shè)備。

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

我們建議最小化應(yīng)用請(qǐng)求的權(quán)限數(shù)量，不具有訪問敏感資料的權(quán)限可以減少無意中濫用這些權(quán)限的風(fēng)險(xiǎn)，可以增加用戶接受度，并且減少應(yīng)用被攻擊者攻擊利用的可能性。

如果你的應(yīng)用可以設(shè)計(jì)成不需要任何權(quán)限，那最好不過。例如：與其請(qǐng)求訪問設(shè)備信息來建立一個(gè)標(biāo)識(shí)，不如建立一個(gè)GUID（這個(gè)例子在下文“處理用戶數(shù)據(jù)”中有說明）。

除了請(qǐng)求權(quán)限之外，你的應(yīng)用可以使用permissions來保護(hù)可能會(huì)暴露給其他應(yīng)用的安全敏感的IPC：比如ContentProvider。通常來說，我們建議使用訪問控制而不是用戶權(quán)限確認(rèn)許可，因?yàn)闄?quán)限會(huì)使用戶感到困惑。例如，考慮在權(quán)限設(shè)置上為應(yīng)用間的IPC通信使用單一開發(fā)者提供的簽名保護(hù)級(jí)別。

不要泄漏受許可保護(hù)的數(shù)據(jù)。只有當(dāng)應(yīng)用通過IPC暴露數(shù)據(jù)才會(huì)發(fā)生這種情況，因?yàn)樗哂刑厥鈾?quán)限，卻不要求任何客戶端的IPC接口有那樣的權(quán)限。更多關(guān)于這方面的潛在影響以及這種問題發(fā)生的頻率在USENIX: http://www.cs.be rkeley.edu/~afelt/felt_usenixsec2011.pdf研究論文中都有說明。

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

通常，你應(yīng)該力求建立擁有盡量少權(quán)限的應(yīng)用，直至滿足你的安全需要。建立一個(gè)新的權(quán)限對(duì)于大多數(shù)應(yīng)用相對(duì)少見，因?yàn)?a rel="external nofollow" target="_blank" target="_blank">系統(tǒng)定義的許可覆蓋很多情況。在適當(dāng)?shù)牡胤绞褂靡呀?jīng)存在的許可執(zhí)行訪問檢查。

如果必須建立一個(gè)新的權(quán)限，考慮能否使用signature protection level來完成你的任務(wù)。簽名許可對(duì)用戶是透明的并且只允許相同開發(fā)者簽名的應(yīng)用訪問，與應(yīng)用執(zhí)行權(quán)限檢查一樣。如果你建立一個(gè)dagerous protction level，那么用戶需要決定是否安裝這個(gè)應(yīng)用。這會(huì)使其他開發(fā)者困惑，也使用戶困惑。

如果你要建立一個(gè)危險(xiǎn)的許可，則會(huì)有多種復(fù)雜情況需考慮：

• 對(duì)于用戶將要做出的安全決定，許可需要用字符串對(duì)其進(jìn)行簡短的表述。
• 許可字符串必須保證語言的國際化。
• 用戶可能對(duì)一個(gè)許可感到困惑或者知曉風(fēng)險(xiǎn)而選擇不安裝應(yīng)用
• 當(dāng)許可的創(chuàng)造者未安裝的時(shí)候，應(yīng)用可能要求許可。

上面每一個(gè)因素都為應(yīng)用開發(fā)者帶來了重要的非技術(shù)挑戰(zhàn)，同時(shí)也使用戶感到困惑，這也是我們不建議使用危險(xiǎn)許可的原因。

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

網(wǎng)絡(luò)交易具有很高的安全風(fēng)險(xiǎn)，因?yàn)樗婕暗絺魉退饺说臄?shù)據(jù)。人們對(duì)移動(dòng)設(shè)備的隱私關(guān)注日益加深，特別是當(dāng)設(shè)備進(jìn)行網(wǎng)絡(luò)交易時(shí)，因此應(yīng)用采取最佳方式保護(hù)用戶數(shù)據(jù)安全極為重要。

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

Android下的網(wǎng)絡(luò)與Linux環(huán)境下的差別并不大。主要考慮的是確保對(duì)敏感數(shù)據(jù)采用了適當(dāng)?shù)膮f(xié)議，比如使用HTTPS進(jìn)行網(wǎng)絡(luò)傳輸。我們?cè)谌魏沃С諬TTPS的服務(wù)器上更愿意使用HTTPS而不是HTTP，因?yàn)橐苿?dòng)設(shè)備可能會(huì)頻繁連接不安全的網(wǎng)絡(luò)，比如公共WiFi熱點(diǎn)。

授權(quán)且加密的套接層級(jí)別的通信可通過使用SSLSocket類輕松實(shí)現(xiàn)?？紤]到Android設(shè)備使用WiFi連接不安全網(wǎng)絡(luò)的頻率，對(duì)于所有應(yīng)用來說，使用安全網(wǎng)絡(luò)是極力鼓勵(lì)支持的。

我們發(fā)現(xiàn)部分應(yīng)用使用localhost端口處理敏感的IPC。我們不鼓勵(lì)這種方法，是因?yàn)檫@些接口可被設(shè)備上的其他應(yīng)用訪問。相反，你應(yīng)該在可認(rèn)證的地方使用Android IPC機(jī)制，例如Service（比使用回環(huán)還糟的是綁定INADDR_ANY，因?yàn)槟愕膽?yīng)用可能收到來自任何地方來的請(qǐng)求，我們也已經(jīng)見識(shí)過了）。

一個(gè)有必要重復(fù)的常見議題是，確保不信任從HTTP或者其他不安全協(xié)議下載的數(shù)據(jù)。這包括在WebView中的輸入驗(yàn)證和對(duì)于http的任何響應(yīng)。

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

SMS協(xié)議是Android開發(fā)者使用最頻繁的電話協(xié)議，主要為用戶與用戶之間的通信設(shè)計(jì)，但對(duì)于想要傳送數(shù)據(jù)的應(yīng)用來說并不合適。由于SMS的限制性，我們強(qiáng)烈建議使用Google Cloud Messaging（GCM）和IP網(wǎng)絡(luò)從web服務(wù)器發(fā)送數(shù)據(jù)消息給用戶設(shè)備應(yīng)用。

很多開發(fā)者沒有意識(shí)到SMS在網(wǎng)絡(luò)上或者設(shè)備上是不加密的，也沒有牢固驗(yàn)證。特別是任何SMS接收者應(yīng)該預(yù)料到惡意用戶也許已經(jīng)給你的應(yīng)用發(fā)送了SMS：不要指望未驗(yàn)證的SMS數(shù)據(jù)執(zhí)行敏感操作。你也應(yīng)該注意到SMS在網(wǎng)絡(luò)上也許會(huì)遭到冒名頂替并且/或者攔截，對(duì)于Android設(shè)備本身，SMS消息是通過廣播intent傳遞的，所以他們也許會(huì)被其他擁有READ_SMS許可的應(yīng)用截獲。

輸入驗(yàn)證

無論應(yīng)用運(yùn)行在什么平臺(tái)上，功能不完善的輸入驗(yàn)證是最常見的影響應(yīng)用安全問題之一。Android有平臺(tái)級(jí)別的對(duì)策，用于減少應(yīng)用的公開輸入驗(yàn)證問題，你應(yīng)該在可能的地方使用這些功能。同樣需要注意的是，選擇類型安全的語言能減少輸入驗(yàn)證問題。

如果你使用native代碼，那么任何從文件讀取的，通過網(wǎng)絡(luò)接收的，或者通過IPC接收的數(shù)據(jù)都有可能引發(fā)安全問題。最常見的問題是buffer overflows，use after free，和off-by-one。Android提供安全機(jī)制比如ASLR和DEP以減少這些漏洞的可利用性，但是沒有解決基本的問題。小心處理指針和管理緩存可以預(yù)防這些問題。

動(dòng)態(tài)、基于字符串的語言，比如JavaScript和SQL，都常受到由轉(zhuǎn)義字符和腳本注入帶來的輸入驗(yàn)證問題。

如果你使用提交到SQL Database或者Content Provider的數(shù)據(jù)，SQL注入也許是個(gè)問題。最好的防御是使用參數(shù)化的查詢，就像ContentProviders中討論的那樣。限制權(quán)限為只讀或者只寫可以減少SQL注入的潛在危害。

如果你不能使用上面提到的安全功能，我們強(qiáng)烈建議使用結(jié)構(gòu)嚴(yán)謹(jǐn)?shù)臄?shù)據(jù)格式并且驗(yàn)證符合期望的格式。黑名單策略與替換危險(xiǎn)字符是有效的，但這些技術(shù)在實(shí)踐中是易錯(cuò)的并且當(dāng)錯(cuò)誤可能發(fā)生的時(shí)候應(yīng)該盡量避免。

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

通常來說，處理用戶數(shù)據(jù)安全最好的方法是最小化獲取敏感數(shù)據(jù)用戶個(gè)人數(shù)據(jù)的API使用。如果你對(duì)數(shù)據(jù)進(jìn)行訪問并且可以避免存儲(chǔ)或傳輸，那就不要存儲(chǔ)和傳輸數(shù)據(jù)。最后，思考是否有一種應(yīng)用邏輯可能被實(shí)現(xiàn)為使用hash或者不可逆形式的數(shù)據(jù)。例如，你的應(yīng)用也許使用一個(gè)email地址的hash作為主鍵，避免傳輸或存儲(chǔ)email地址，這減少無意間泄漏數(shù)據(jù)的機(jī)會(huì)，并且也能減少攻擊者嘗試?yán)媚愕膽?yīng)用的機(jī)會(huì)。

如果你的應(yīng)用訪問私人數(shù)據(jù)，比如密碼或者用戶名，記住司法也許要求你提供一個(gè)使用和存儲(chǔ)這些數(shù)據(jù)的隱私策略的解釋。所以遵守最小化訪問用戶數(shù)據(jù)最佳的安全實(shí)踐也許只是簡單的服從。

你也應(yīng)該考慮到應(yīng)用是否會(huì)疏忽暴露個(gè)人信息給其他方，比如廣告第三方組件或者你應(yīng)用使用的第三方服務(wù)。如果你不知道為什么一個(gè)組件或者服務(wù)請(qǐng)求個(gè)人信息，那么就不要提供給它。通常來說，通過減少應(yīng)用訪問個(gè)人信息，會(huì)減少這個(gè)區(qū)域潛在的問題。

如果必須訪問敏感數(shù)據(jù)，評(píng)估這個(gè)信息是否必須要傳到服務(wù)器，或者是否可以被客戶端操作?？紤]客戶端上使用敏感數(shù)據(jù)運(yùn)行的任何代碼，避免傳輸用戶數(shù)據(jù) 確保不會(huì)無意間通過過渡自由的IPC、world writable文件、或網(wǎng)絡(luò)socket暴露用戶數(shù)據(jù)給其他設(shè)備上的應(yīng)用。這里有一個(gè)泄漏權(quán)限保護(hù)數(shù)據(jù)的特別例子，在Requesting Permissions章節(jié)中討論。

如果需要GUID，建立一個(gè)大的、唯一的數(shù)字并保存它。不要使用電話標(biāo)識(shí)，比如與個(gè)人信息相關(guān)的電話號(hào)碼或者IMEI。這個(gè)話題在Android Developer Blog中有更詳細(xì)的討論。

應(yīng)用開發(fā)者應(yīng)謹(jǐn)慎的把log寫到機(jī)器上。在Android中，log是共享資源，一個(gè)帶有READ_LOGS許可的應(yīng)用可以訪問。即使電話log數(shù)據(jù)是臨時(shí)的并且在重啟之后會(huì)擦除，不恰當(dāng)?shù)赜涗浻脩粜畔?huì)無意間泄漏用戶數(shù)據(jù)給其他應(yīng)用。

使用WebView

因?yàn)?a rel="external nofollow" target="_blank" rel="external nofollow" target="_blank" target="_blank">WebView能包含HTML和JavaScript瀏覽網(wǎng)絡(luò)內(nèi)容，不恰當(dāng)?shù)氖褂脮?huì)引入常見的web安全問題，比如跨站腳本攻擊（JavaScript注入）。Android采取一些機(jī)制通過限制WebView的能力到應(yīng)用請(qǐng)求功能最小化來減少這些潛在的問題。

如果你的應(yīng)用沒有在WebView內(nèi)直接使用JavaScript，不要調(diào)用setJavaScriptEnabled()。某些樣本代碼使用這種方法，可能會(huì)導(dǎo)致在產(chǎn)品應(yīng)用中改變用途：所以如果不需要的話移除它。默認(rèn)情況下WebView不執(zhí)行JavaScript，所以跨站腳本攻擊不會(huì)產(chǎn)生。

使用addJavaScriptInterface()要特別的小心，因?yàn)樗试SJavaScript執(zhí)行通常保留給Android應(yīng)用的操作。只把addJavaScriptInterface()暴露給可靠的輸入源。如果不受信任的輸入是被允許的，不受信任的JavaScript也許會(huì)執(zhí)行Android方法。總得來說，我們建議只把addJavaScriptInterface()暴露給你應(yīng)用內(nèi)包含的JavaScript。

如果你的應(yīng)用通過WebView訪問敏感數(shù)據(jù)，你也許想要使用clearCache()方法來刪除任何存儲(chǔ)到本地的文件。服務(wù)端的header，比如no-cache，能用于指示應(yīng)用不應(yīng)該緩存特定的內(nèi)容。

處理證書

通常來說，我們建議請(qǐng)求用戶證書頻率最小化--使得釣魚攻擊更明顯，并且降低其成功的可能。取而代之使用授權(quán)令牌然后刷新它。

可能的情況下，用戶名和密碼不應(yīng)該存儲(chǔ)到設(shè)備上，而使用用戶提供的用戶名和密碼執(zhí)行初始認(rèn)證，然后使用一個(gè)短暫的、特定服務(wù)的授權(quán)令牌?？梢员欢鄠€(gè)應(yīng)用訪問的service應(yīng)該使用AccountManager訪問。 如果可能的話，使用AccountManager類來執(zhí)行基于云的服務(wù)并且不把密碼存儲(chǔ)到設(shè)備上。

使用AccountManager獲取Account之后，進(jìn)入任何證書前檢查CREATOR，這樣你就不會(huì)因?yàn)槭韬龆炎C書傳遞給錯(cuò)誤的應(yīng)用。

如果證書只是用于你創(chuàng)建的應(yīng)用，那么你能使用checkSignature()驗(yàn)證訪問AccountManager的應(yīng)用。或者，如果一個(gè)應(yīng)用要使用證書，你可以使用KeyStore來儲(chǔ)存。

使用加密

除了采取數(shù)據(jù)隔離，支持完整的文件系統(tǒng)加密，提供安全信道之外。Android提供大量加密算法來保護(hù)數(shù)據(jù)。

通常來說，嘗試使用最高級(jí)別的已存在framework的實(shí)現(xiàn)來支持，如果你需要安全的從一個(gè)已知的位置取回一個(gè)文件，一個(gè)簡單的HTTPS URI也許就足夠了，并且這部分不要求任何加密知識(shí)。如果你需要一個(gè)安全信道，考慮使用HttpsURLConnection或者SSLSocket要比使用你自己的協(xié)議好。

如果你發(fā)現(xiàn)的確需要實(shí)現(xiàn)一個(gè)自定義的協(xié)議，我們強(qiáng)烈建議你不要自己實(shí)現(xiàn)加密算法。使用已經(jīng)存在的加密算法，比如Cipher類中提供的AES或者RSA。

使用一個(gè)安全的隨機(jī)數(shù)生成器（SecureRandom）來初始化加密密鑰（KeyGenerator）。使用一個(gè)不安全隨機(jī)數(shù)生成器生成的密鑰嚴(yán)重削弱算法的優(yōu)點(diǎn)，而且可能遭到離線攻擊。

如果你需要存儲(chǔ)一個(gè)密鑰來重復(fù)使用，使用類似于KeyStore的機(jī)制，來提供長期儲(chǔ)存和檢索加密密鑰的功能。

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

一些Android應(yīng)用試圖使用傳統(tǒng)的Linux技術(shù)實(shí)現(xiàn)IPC，比如網(wǎng)絡(luò)socket和共享文件。我們強(qiáng)烈鼓勵(lì)使用Android系統(tǒng)IPC功能，比如Intent，Binder，Messenger和BroadcastReceiver。Android IPC機(jī)制允許你為每一個(gè)IPC機(jī)制驗(yàn)證連接到你的IPC和設(shè)置安全策略的應(yīng)用的身份。

很多安全元素通過IPC機(jī)制共享。Broadcast Receiver, Activitie,和Service都在應(yīng)用的manifest中聲明。如果你的IPC機(jī)制不打算給其他應(yīng)用使用，設(shè)置android:exported屬性為false。這對(duì)于同一個(gè)UID內(nèi)包含多個(gè)進(jìn)程的應(yīng)用，或者在開發(fā)后期決定不想通過IPC暴露功能并且不想重寫代碼的時(shí)候非常有用。

如果你的IPC打算讓別的應(yīng)用訪問，你可以通過使用Permission標(biāo)記設(shè)置一個(gè)安全策略。如果IPC是使用同一個(gè)密鑰簽名的獨(dú)立的應(yīng)用間的，使用signature更好一些。

使用Intent

Intent是Android中異步IPC機(jī)制的首選。根據(jù)你應(yīng)用的需求，你也許使用sendBroadcast()，sendOrderedBroadcast()或者直接的intent來指定一個(gè)應(yīng)用組件。

注意，有序廣播可以被Receiver接收，所以他們也許不會(huì)被發(fā)送到所有的應(yīng)用中。 如果你要發(fā)送一個(gè)intent給指定的Receiver，這個(gè)intent必須被直接的發(fā)送給這個(gè)Receiver。

Intent的發(fā)送者能在發(fā)送的時(shí)候驗(yàn)證Receiver是否有一個(gè)許可指定了一個(gè)non-Null Permission。只有有那個(gè)許可的應(yīng)用才會(huì)收到這個(gè)intent。如果廣播intent內(nèi)的數(shù)據(jù)是敏感的，你應(yīng)該考慮使用許可來保證惡意應(yīng)用沒有恰當(dāng)?shù)脑S可無法注冊(cè)接收那些消息。這種情況下，可以考慮直接執(zhí)行這個(gè)Receiver而不是發(fā)起一個(gè)廣播。

注意：Intent過濾器不能作為安全特性--組件可被intent顯式調(diào)用，可能會(huì)沒有符合intent過濾器的數(shù)據(jù)。你應(yīng)該在Intent Receiver內(nèi)執(zhí)行輸入驗(yàn)證，確認(rèn)對(duì)于調(diào)用Receiver，Service、或Activity來說格式正確合理。

使用服務(wù)

Service經(jīng)常被用于為其他應(yīng)用提供服務(wù)。每個(gè)service類必須在它的manifest文件進(jìn)行相應(yīng)的聲明。

默認(rèn)情況下，Service不能被導(dǎo)出和被其他應(yīng)用執(zhí)行。如果你加入了任何Intent過濾器到服務(wù)的聲明中，那么它默認(rèn)為可以被導(dǎo)出。最好明確聲明android:exported元素來確定它按照你設(shè)想的運(yùn)行?？梢允褂?a rel="external nofollow" target="_blank" target="_blank">android:permission保護(hù)Service。這樣做，其他應(yīng)用在他們自己的manifest文件中將需要聲明相應(yīng)的元素來啟動(dòng)、停止或者綁定到這個(gè)Service上。

一個(gè)Service可以使用許可保護(hù)單獨(dú)的IPC調(diào)用，在執(zhí)行調(diào)用前通過調(diào)用checkCallingPermission()來實(shí)現(xiàn)。我們建議使用manifest中聲明的許可，因?yàn)槟切┦遣蝗菀妆O(jiān)管的。

使用binder和messenger接口

在Android中，Binders和Messenger是RPC風(fēng)格IPC的首選機(jī)制。必要的話，他們提供一個(gè)定義明確的接口，促進(jìn)彼此的端點(diǎn)認(rèn)證。

我們強(qiáng)烈鼓勵(lì)在一定程度上，設(shè)計(jì)不要求指定許可檢查的接口。Binder和Messenger不在應(yīng)用的manifest中聲明，因此你不能直接在Binder上應(yīng)用聲明的許可。它們?cè)趹?yīng)用的manifest中繼承許可聲明，Service或者Activity內(nèi)實(shí)現(xiàn)了許可。如果你打算創(chuàng)建一個(gè)接口，在一個(gè)指定binder接口上要求認(rèn)證和/或者訪問控制，這些控制必須在Binder和Messenger的接口中明確添加代碼。

如果提供一個(gè)需要訪問控制的接口，使用checkCallingPermission()來驗(yàn)證調(diào)用者是否擁有必要的許可。由于你的應(yīng)用的id已經(jīng)被傳遞到別的接口，因此代表調(diào)用者訪問一個(gè)Service之前這尤其重要。如果調(diào)用一個(gè)Service提供的接口，如果你沒有對(duì)給定的Service訪問許可，bindService()請(qǐng)求也許會(huì)失敗。如果調(diào)用你自己的應(yīng)用提供的本地接口，使用clearCallingIdentity()來進(jìn)行內(nèi)部安全檢查是有用的。

更多關(guān)于用服務(wù)運(yùn)行IPC的信息，參見Bound Services

利用BroadcastReceiver

Broadcast receivers是用來處理通過intent發(fā)起的異步請(qǐng)求。

默認(rèn)情況下，Receiver是導(dǎo)出的，并且可以被任何其他應(yīng)用執(zhí)行。如果你的BroadcastReceiver打算讓其他應(yīng)用使用，你也許想在應(yīng)用的manifest文件中使用元素對(duì)receiver使用安全許可。這將阻止沒有恰當(dāng)許可的應(yīng)用發(fā)送intent給這個(gè)BroadcastReceiver。

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

我們不鼓勵(lì)從應(yīng)用文件外加載代碼?？紤]到代碼注入或者代碼篡改，這樣做顯著增加了應(yīng)用暴露的可能，同時(shí)也增加了版本管理和應(yīng)用測(cè)試的復(fù)雜性。最終可能造成無法驗(yàn)證應(yīng)用的行為，因此在某些環(huán)境下應(yīng)該被限制。

如果你的應(yīng)用確實(shí)動(dòng)態(tài)加載了代碼，最重要的事情是記住運(yùn)行動(dòng)態(tài)加載的代碼與應(yīng)用具有相同的安全許可。用戶決定安裝你的應(yīng)用是基于你的id，他們期望你提供任何運(yùn)行在應(yīng)用內(nèi)部的代碼，包括動(dòng)態(tài)加載的代碼。

動(dòng)態(tài)加載代碼主要的風(fēng)險(xiǎn)在于代碼來源于可確認(rèn)的源頭。 如果這個(gè)模塊是之間直接包含在你的應(yīng)用中，那么它們不能被其他應(yīng)用修改，不論代碼是本地庫或者是使用DexClassLoader加載的類這都是事實(shí)。我們見過很多應(yīng)用實(shí)例嘗試從不安全的地方加載代碼，比如從網(wǎng)絡(luò)上通過非加密的協(xié)議或者從全局可寫的位置（比如外部存儲(chǔ)）下載數(shù)據(jù)。這些地方會(huì)允許網(wǎng)絡(luò)上其他人在傳輸過程中修改其內(nèi)容，或者允許用戶設(shè)備上的其他應(yīng)用修改其內(nèi)容。

在虛擬機(jī)器安全性

Dalvik是安卓的運(yùn)行時(shí)虛擬機(jī)(VM)。Dalvik是特別為安卓建立的，但許多其他虛擬機(jī)相關(guān)的安全代碼的也適用于安卓。一般來說，你不應(yīng)該關(guān)心與自己有關(guān)的虛擬機(jī)的安全問題。你的應(yīng)用程序在一個(gè)安全的沙盒環(huán)境下運(yùn)行，所以系統(tǒng)上的其他進(jìn)程無法訪問你的代碼或私人數(shù)據(jù)。

如果你想更深入了解虛擬機(jī)的安全問題，我們建議您熟悉一些現(xiàn)有文獻(xiàn)的主題。推薦兩個(gè)比較流行的資源：

• http://www.securingjava.com/toc.html
• https://www.owasp.org/index.php/Java_Security_Resources

這個(gè)文檔集中于安卓與其他VM環(huán)境不同地方。對(duì)于有在其他環(huán)境下有VM編程經(jīng)驗(yàn)開發(fā)者來說，這里有兩個(gè)普遍的問題可能對(duì)于編寫Android應(yīng)用來說有些不同：

• 一些虛擬機(jī)，比如JVM或者.Net，擔(dān)任一個(gè)安全的邊界作用，代碼與底層操作系統(tǒng)隔離。在Android上，Dalvik VM不是一個(gè)安全邊界：應(yīng)用沙箱是在系統(tǒng)級(jí)別實(shí)現(xiàn)的，所以Dalvik可以在同一個(gè)應(yīng)用與native代碼相互操作，沒有任何安全約束。
• 已知的手機(jī)上的存儲(chǔ)限制，對(duì)來發(fā)者來說，想要建立模塊化應(yīng)用和使用動(dòng)態(tài)類加載是很常見的。要這么做的時(shí)候需要考慮兩個(gè)資源：一是在哪里恢復(fù)你的應(yīng)用邏輯，二是在哪里存儲(chǔ)它們。不要從未驗(yàn)證的資源使用動(dòng)態(tài)類加載器，比如不安全的網(wǎng)絡(luò)資源或者外部存儲(chǔ)，因?yàn)槟切┐a可能被修改為包含惡意行為。

本地代碼的安全

一般來說，對(duì)于大多數(shù)應(yīng)用開發(fā)，我們鼓勵(lì)開發(fā)者使用Android SDK而不是使用[Android NDK]（http://developer.android.com/tools/sdk/ndk/index.html) 的native代碼。編譯native代碼的應(yīng)用更為復(fù)雜，移植性差，更容易包含常見的內(nèi)存崩潰錯(cuò)誤，比如緩沖區(qū)溢出。

Android使用Linux內(nèi)核編譯并且與Linux開發(fā)相似，如果你打算使用native代碼，安全策略尤其有用。與Linux有關(guān)的安全問題超出了本文的討論范圍，但讀者可以參考Secure Programming for Linux and Unix HOWTO。

與大多數(shù)Linux環(huán)境的一個(gè)重要區(qū)別是應(yīng)用沙箱。在Android中，所有的應(yīng)用運(yùn)行在應(yīng)用沙箱中，包括用native代碼編寫的應(yīng)用。在最基本的級(jí)別中，與Linux相似，對(duì)于開發(fā)者來說最好的方式是知道每個(gè)應(yīng)用被分配一個(gè)權(quán)限非常有限的唯一UID。這里討論的比Android Security Overview中更細(xì)節(jié)化，你應(yīng)該熟悉應(yīng)用許可，即使你使用的是native代碼。