Android 巢狀 Intent 隱患及解決方案

前言：

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

大家 App 是否在某些情況下對外提供了一個 Service 來執行啟動其他 App 的 Activity 元件的回撥。比如說，接收的 Intent 請求會以 extra 引數的形式內嵌著的其他 Intent ，而這個 Intent 引數會被用作 startActivity() 呼叫。

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

如下的內容將解釋採用這種做法會帶來的問題，並提供一個解決方案，來確保你的 App 能以更加安全的方式來實現相同的功能。

帶來的問題

我們期望這種型別的互動，會按照示意圖的設計來進行：

上述流程圖展示瞭如何將一個用來啟動回撥 Activity 的 Intent 新增到啟動 Service 的 Intent 中，以及該 Service 被用作啟動引數提供的 Activity。

Client App 為 ClientCallbackActivity 建立了一個 Intent 範例並將它以 extra 形式新增到了用於其他 Provider App 的 ApiService 的 Intent 屬性中。Provider App 處理完該請求後將使用 Client App 提供的 Intent 來啟動目標 Activity。

注意：這裡需要注意的是 Provider App 呼叫的 startActivity() 採用的是它自己的 Context，這將帶來兩個欠佳的後果。

• 因為 ClientCallbackActivity 將被外部的 Provider App 啟動，所以它需要標記為對外可見即 exported，而這將允許 Provider App 以外的任何其他 App 都可以啟動它
• 傳遞給 ApiService 的巢狀 Intent 可被用來啟動 Provider App 的任何 Activity，包括私有的、有潛在敏感資訊的、對外不可見的所有 Activity！

為了進一步說明，請思考一下如果呼叫方 App 提供的內嵌 Intent 並非指向自己的 Activity，相反其指向了 Provider App 內部的私有 Activity，會發生什麼？

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

因為採用了巢狀 Intent，對於 Provider App 來說很難去防止其他 App 去存取它的私有的、有潛在敏感資訊的 Activity 們。而且 Provider App 直接使用了 startActivity() 去處理 Intent，即便ApiSensitiveActivity 未被宣告為對外可見仍然可以被啟動。

解決方案：PendingIntent

解決方案很簡單：Provider App 不要接收 Intent，而是接收 PendingIntent。原因在於 Intent 和 PendingIntent 的區別： PendingIntent 總是使用建立它的 Context 進行 Intent 的處理。

上述流程圖展示接收 PendingIntent 的話如何使用 App 建立它的 Context 進行處理，這可以阻止存取 Provider App 中非對外可見的 Activity 們。

因為回撥提供的是 PendingIntent 物件，當 Provider App 呼叫它的 send() 時，startActivity() 請求會被當做 Attacker App 這一方進行處理。而 Attacker App 並不具備呼叫 Provider App 中 ApiSensitiveActivity 的特權，所以系統將會阻止這個啟動請求。

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

如果你熟悉 Notification、Alarm Manager 等相關的 API，你應該知道它們採用 PendingIntent 來啟用某些操作以及向 App 發出 alarm 通知。它始終以建立它的 App 身份進行處理，這也是系統選擇 PendingIntent 而非一般 Intent 的原因。

結語

無論是對於 Client App 還是對於 Provider App，採用 Intent 這種機制來實現 Activity 啟動回撥的做法會導致雙方 App 的安全隱患。這源自於 Intent 會在呼叫它的 App 上下文進行處理。而這個上下文造成了 Provider App 中非公開 Activity 被啟動的可能性，同時也迫使 Client App 必須對外公開處理回撥的 Activity。

相較之下，PendingIntent 會在建立它的上下文進行處理。這將允許 Provider App 可以自由使用、不會對外暴露 Activity，同時可以使得 Client App 指定任意 Activity 來處理回撥，包括非公開 Activity。

到此這篇關於Android 巢狀 Intent 隱患及解決方案的文章就介紹到這了,更多相關Android 巢狀 Intent 內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！