前言：

翻譯自 Nicole Borrelli 在 Medium 上的 post 《Android Nesting Intents》。

大家 App 是否在某些情況下對外提供了一個 Service 來執(zhí)行啟動其他 App 的 Activity 組件的回調(diào)。比如說，接收的 Intent 請求會以 extra 參數(shù)的形式內(nèi)嵌著的其他 Intent ，而這個 Intent 參數(shù)會被用作 startActivity() 調(diào)用。

大家有沒有意識到這種做法會讓我們的 App 變得脆弱、易攻擊？

如下的內(nèi)容將解釋采用這種做法會帶來的問題，并提供一個解決方案，來確保你的 App 能以更加安全的方式來實(shí)現(xiàn)相同的功能。

帶來的問題

我們期望這種類型的交互，會按照示意圖的設(shè)計(jì)來進(jìn)行：

上述流程圖展示了如何將一個用來啟動回調(diào) Activity 的 Intent 添加到啟動 Service 的 Intent 中，以及該 Service 被用作啟動參數(shù)提供的 Activity。

Client App 為 ClientCallbackActivity 創(chuàng)建了一個 Intent 實(shí)例并將它以 extra 形式添加到了用于其他 Provider App 的 ApiService 的 Intent 屬性中。Provider App 處理完該請求后將使用 Client App 提供的 Intent 來啟動目標(biāo) Activity。

注意：這里需要注意的是 Provider App 調(diào)用的 startActivity() 采用的是它自己的 Context，這將帶來兩個欠佳的后果。

• 因?yàn)?nbsp;ClientCallbackActivity 將被外部的 Provider App 啟動，所以它需要標(biāo)記為對外可見即 exported，而這將允許 Provider App 以外的任何其他 App 都可以啟動它
• 傳遞給 ApiService 的嵌套 Intent 可被用來啟動 Provider App 的任何 Activity，包括私有的、有潛在敏感信息的、對外不可見的所有 Activity！

為了進(jìn)一步說明，請思考一下如果調(diào)用方 App 提供的內(nèi)嵌 Intent 并非指向自己的 Activity，相反其指向了 Provider App 內(nèi)部的私有 Activity，會發(fā)生什么？

上述流程圖展示了一個精心構(gòu)造的 Intent 如何被用來啟動 Provider App 的 ApiSensitiveActivity，盡管它對外不可見也不應(yīng)該被其他 App 啟動。

因?yàn)椴捎昧饲短?Intent，對于 Provider App 來說很難去防止其他 App 去訪問它的私有的、有潛在敏感信息的 Activity 們。而且 Provider App 直接使用了 startActivity() 去處理 Intent，即便ApiSensitiveActivity 未被聲明為對外可見仍然可以被啟動。

解決方案：PendingIntent

解決方案很簡單：Provider App 不要接收 Intent，而是接收 PendingIntent。原因在于 Intent 和 PendingIntent 的區(qū)別： PendingIntent 總是使用創(chuàng)建它的 Context 進(jìn)行 Intent 的處理。

上述流程圖展示接收 PendingIntent 的話如何使用 App 創(chuàng)建它的 Context 進(jìn)行處理，這可以阻止訪問 Provider App 中非對外可見的 Activity 們。

因?yàn)榛卣{(diào)提供的是 PendingIntent 對象，當(dāng) Provider App 調(diào)用它的 send() 時，startActivity() 請求會被當(dāng)做 Attacker App 這一方進(jìn)行處理。而 Attacker App 并不具備調(diào)用 Provider App 中 ApiSensitiveActivity 的特權(quán)，所以系統(tǒng)將會阻止這個啟動請求。

對于 Provider App 來說這必然很有好處，但是我們自己的 Client App 呢？那么，如之前所說我們提供的是 PendingIntent 類型，ClientCallbackActivity 改為私有、非公開的話一樣可以啟動。也就是說，這種做法增強(qiáng)了雙方 App 的安全。

如果你熟悉 Notification、Alarm Manager 等相關(guān)的 API，你應(yīng)該知道它們采用 PendingIntent 來激活某些操作以及向 App 發(fā)出 alarm 通知。它始終以創(chuàng)建它的 App 身份進(jìn)行處理，這也是系統(tǒng)選擇 PendingIntent 而非一般 Intent 的原因。

結(jié)語

無論是對于 Client App 還是對于 Provider App，采用 Intent 這種機(jī)制來實(shí)現(xiàn) Activity 啟動回調(diào)的做法會導(dǎo)致雙方 App 的安全隱患。這源自于 Intent 會在調(diào)用它的 App 上下文進(jìn)行處理。而這個上下文造成了 Provider App 中非公開 Activity 被啟動的可能性，同時也迫使 Client App 必須對外公開處理回調(diào)的 Activity。

相較之下，PendingIntent 會在創(chuàng)建它的上下文進(jìn)行處理。這將允許 Provider App 可以自由使用、不會對外暴露 Activity，同時可以使得 Client App 指定任意 Activity 來處理回調(diào)，包括非公開 Activity。

到此這篇關(guān)于Android 嵌套 Intent 隱患及解決方案的文章就介紹到這了,更多相關(guān)Android 嵌套 Intent 內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論