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。
可以檢視 《不安全的 intent 啟動》 這篇文章瞭解 Android 系統如何幫助 App 減少巢狀 Intent 的影響。
參考
- Android 車機初體驗:Auto,Automotive 傻傻分不清楚?
- 深入分析 Android 系統返回手勢的實現原理
- Android 13 返回導航大變更:返回鍵徹底廢棄 可預見型返回手勢
- 從顯示 Tap 位置的原理一探 Android Input 系統
- Android 巢狀 Intent 的隱患以及解決方案
- Android 13 針對 Intent filters 安全的再加強
- Android 13 新的換行策略和針對日文的優化
- 電子廠裡撂了挑子,我默默自學起了Android|2021 年中總結
- 鴻蒙Harmony談了這麼久,和Android到底啥區別?
- Jetpack新成員SplashScreen:打造全新的App啟動畫面
- MAD,現代安卓開發技術:Android 領域開發方式的重大變革!
- 傾情分享:Android 開發者們無法錯過的網站寶藏~
- Jetpack 叒一新成員 DragAndDrop 框架:大大簡化拖放手勢開發!
- 都 2021 年了,還有人在研究 Handler?
- Looper 需要手動 quit,那主執行緒 Looper 呢?
- 重新理解為什麼 Handler 可能導致記憶體洩露?
- 萬字覆盤 Handler 中各式 Message 的使用和原理
- Handler 的 Message 例項怎麼建立,為什麼不是直接 new?