在上一期中，我們討論了攻擊及加固Activity組件的方法，今天我們來看看所謂的”Content Provider Leakage”。

什么是Content Provider?

按照Google為Android設計的安全模型，應用的數據屬于私有數據，故默認情況下，應用無法訪問其他應用的私有數據。但當應用需要與其他應用共享數據時，Content Provider就扮演著應用間數據共享橋梁的角色。Content Providers使用標準的insert(),query(),update(), delete()等方法來操作應用的數據，每個Content Provider都對應一個以”content://”開頭的特定URI，任何應用都可以通過這個URI操作Content Provider 應用的數據庫。
某些時候，應用的Content Provider并不是為了與其他應用共享數據，或者是為了與具有一定權限的應用共享數據，在這種情況下，如果應用對權限控制不當就會造成信息泄露。

Android中內置的SMS短信應用就是一個典型的Content Provider的例子，任何應用都能通過這個URI讀取收件箱：content://sms/inbox，但必須在應用的AndroidManifest.xml文件中登記READ_SMS權限。

前期準備：

   安裝了Android SDK的電腦

   一臺未root的Android設備

示例程序功能測試：

下載了測試應用之后，安裝在一個未root的android設備中

可通過以下命令安裝

#adb install <name of the apk>.apk

我們的目標是尋找該應用是否實現了Content Provider，如果有，我們就需要進一步對其進行測試看是否會造成信息泄露。

相關主題：

   信息收集

   攻擊脆弱的Content Provider

   應用加固

信息收集:

與其他的滲透測試步驟一樣，我們同樣從信息收集入手。假設現在我們都拿到了APK文件，使用我們第一期介紹的方法反編譯該APK文件，檢查在APK的AndroidManifest.xml文件中注冊的content provider。并檢查所有用到了相關URI的smali文件。

Content provider 通常以如下形式在AndroidManifest.xml中注冊

檢查測試應用的AndroidManifest.xml文件：

我們在AndroidManifest.xml文件中發現其中注冊了一個content provider ，并且該content provider 是暴露的(android:exported=”true”)，這意味著所有應用都可以訪問這個content provider

攻擊content provider

這是我們這次試驗最有趣的部分了，現在我們嘗試通過這個content provider 去查詢數據，如果有數據返回，就意味著這個content provider 是可以被攻擊的，我們有很多種辦法來進行這個查詢:

1、 使用adb命令

2、 使用一個惡意應用發起查詢

3、 使用Mercury框架（譯者注：以改名為drozer）

使用adb

   要使用adb來訪問content provider,測試應用要先安裝在一臺供測試的設備上。

   首先獲得一個adb shell (cmd: # adb shell)，并使用下面的命令來讀取content provider.比如我現在要去的讀取一個在MyProvider.smali中發現的URI：

   Content –query –uri content://com.isi.contentprovider.MyProvider/udetails

不出意外的話，我們就能看到儲存在應用數據庫中的內容了，如下圖所示：

使用惡意應用

我們甚至能自己寫一個簡單的惡意應用來讀取content provider。以下一段讀取收件箱的示例代碼：

使用Mercury框架(drozer)

使用mercury框架，整個攻擊過程將更加簡單和高效。

標題加固應用

1、 設置android:exported 屬性為false:

在我們這個應用的AndroidManifest.xml文件中，我們應該加上以下屬性來對應用進行加固，比如，我們的content provider 的類名是com.isi.contentprovider.MyProvider

如果我再嘗試讀取一個屬性android:exported 為false的content provider就會拋出異常，如圖所示：
注：API level 在17以下的所有應用的android:exported屬性默認值都為true.

2、 通過設置自定義權限來限制對content provider的訪問

我們可以通過自定義權限來對content provider的訪問進行權限控制.這在開發者想對具有特定權限的應用開放訪問的情況下很有用。

標題Content Provider的其他安全問題

SQL注入：如果安全控制不當，Content Provider 會造成客戶端的SQL注入，與傳統的SQL注入攻擊方法類似。

目錄遍歷：如果Content Provider的實現存在問題，可能還會造成目錄遍歷。這與WEB中的目錄遍歷類似，允許攻擊者遍歷并訪問本地文件系統。可通過該漏洞讀取設備中的敏感文件。