摘要：人工排查肯定比較麻煩，建議開發(fā)者使用阿里聚安全提供的安全掃描服務(wù)，在上線前進(jìn)行自動(dòng)化的安全掃描，盡早發(fā)現(xiàn)并規(guī)避這樣的風(fēng)險(xiǎn)。

作者：伊樵、呆狐@阿里聚安全

Content Provider組件是Android應(yīng)用的重要組件之一，管理對(duì)數(shù)據(jù)的訪問(wèn)，主要用于不同的應(yīng)用程序之間實(shí)現(xiàn)數(shù)據(jù)共享的功能。Content Provider的數(shù)據(jù)源不止包括SQLite數(shù)據(jù)庫(kù)，還可以是文件數(shù)據(jù)。通過(guò)將數(shù)據(jù)儲(chǔ)存層和應(yīng)用層分離，Content Provider為各種數(shù)據(jù)源提供了一個(gè)通用的接口。

創(chuàng)建一個(gè)自己的Content Provider需要繼承自ContentProvider抽象類，需要重寫其中的onCreate()、query()、insert()、update()、delete()、getType()六個(gè)抽象方法，這些方法實(shí)現(xiàn)對(duì)底層數(shù)據(jù)源的增刪改查等操作。還需在AndroidManifest文件注冊(cè)Content Provider，注冊(cè)時(shí)指定訪問(wèn)權(quán)限、exported屬性、authority屬性值等。

其它APP使用ContentResolver對(duì)象來(lái)查詢和操作Content Provider，此對(duì)象具有Content Provider中同名的方法名。這樣其他APP接就可以訪問(wèn)Content Provider對(duì)應(yīng)的數(shù)據(jù)源的底層數(shù)據(jù)，而無(wú)須知道數(shù)據(jù)的結(jié)構(gòu)或?qū)崿F(xiàn)。
如何定位到具體的數(shù)據(jù)？
采用Content Uri，一個(gè)Content Uri如下所示：

content://com.jaq.providertest.friendsprovider/friends

它的組成一般分為三部分：
1) content://:作為 content Uri的特殊標(biāo)識(shí)(必須);
2) 權(quán)(authority):用于唯一標(biāo)識(shí)這個(gè)Content Provider，外部訪問(wèn)者可以根據(jù)這個(gè)標(biāo)識(shí)找到它；在AndroidManifest中也配置的有；
3) 路徑(path): 所需要訪問(wèn)數(shù)據(jù)的路徑，根據(jù)業(yè)務(wù)而定。

這些內(nèi)容就不具體展開詳談了，詳見參考1。

如果在AndroidManifest文件中將某個(gè)Content Provider的exported屬性設(shè)置為true，則多了一個(gè)攻擊該APP的攻擊點(diǎn)。如果此Content Provider的實(shí)現(xiàn)有問(wèn)題，則可能產(chǎn)生任意數(shù)據(jù)訪問(wèn)、SQL注入、目錄遍歷等風(fēng)險(xiǎn)。

私有權(quán)限定義經(jīng)常發(fā)生的風(fēng)險(xiǎn)是：定義了私有權(quán)限，但是卻根本沒(méi)有定義私有權(quán)限的級(jí)別，或者定義的權(quán)限級(jí)別不夠，導(dǎo)致惡意應(yīng)用只要聲明這個(gè)權(quán)限就能夠訪問(wèn)到相應(yīng)的Content Provider提供的數(shù)據(jù)，造成數(shù)據(jù)泄露。

以公開的烏云漏洞WooYun-2014-57590為例：
某網(wǎng)盤客戶端使用了自己的私有權(quán)限，但是在AndroidManifest中卻沒(méi)有定義私有權(quán)限，其它APP只要聲明這個(gè)權(quán)限就能訪問(wèn)此網(wǎng)盤客戶端提供的Provider，從而訪問(wèn)到用戶數(shù)據(jù)。
在網(wǎng)盤客戶端的AndroidManifest中注冊(cè)Provider時(shí)，聲明了訪問(wèn)時(shí)需要的讀寫權(quán)限，并且權(quán)限為客戶端自定義的私有權(quán)限：

但是在AndroidManifest中卻沒(méi)有見到私有權(quán)限“com.huawei.dbank.v7.provider.DBank.READ_DATABASE”和“com.huawei.dbank.v7.provider.DBank.WRITE_DATABASE”的定義：

反編譯客戶端后查看到的URI，根據(jù)這些可以構(gòu)造訪問(wèn)到Provider的URI：

編寫POC
以查看網(wǎng)盤下載的文件列表為例，
在POC的AndroidManifest中聲明私有權(quán)限，權(quán)限的保護(hù)級(jí)別定義為最低級(jí)“normal”：

主要代碼為：

拿到數(shù)據(jù)庫(kù)中保存的下載列表數(shù)據(jù)：

對(duì)應(yīng)的數(shù)據(jù)庫(kù)：

這樣任意的惡意應(yīng)用程序就可以訪問(wèn)到用戶網(wǎng)盤的上傳、下載記錄，網(wǎng)盤里面存的文件列表等隱私信息。

再以公開的烏云漏洞wooyun-2013-039697為例：

定義了私有權(quán)限，但是保護(hù)等級(jí)設(shè)置成為了dangerous或者normal，這樣的保護(hù)等級(jí)對(duì)于一些應(yīng)用的Provide重要性相比保護(hù)級(jí)低了。
Provider為：

私有權(quán)限“com.renren.mobile.android.permission.PERMISSION_ADD_ACCOUNT”的定義為：

反編譯客戶端，看到AcountProvider對(duì)應(yīng)的實(shí)現(xiàn)：

編寫POC：
在AndroidManifest中定義和聲明權(quán)限：

主要代碼為：

可看到用戶的賬戶信息，包括uid，手機(jī)號(hào)，加密后的密碼等：

當(dāng)Content Provider的數(shù)據(jù)源是SQLite數(shù)據(jù)庫(kù)時(shí)，如果實(shí)現(xiàn)不當(dāng)，而Provider又是暴露的話，則可能會(huì)引發(fā)本地SQL注入漏洞。
Content Provider的query( )的方法定義為：

其中參數(shù)：

uri:為content Uri，要查詢的數(shù)據(jù)庫(kù)
projection：為要查詢的列名
selection和selectionArgs：要指定查詢條件
sortOrder：查詢結(jié)果如何排序

query() 與 SQL 查詢對(duì)比如下：

如果query( )中使用的是拼接字符串組成SQL語(yǔ)句的形式去查詢底層的SQLite數(shù)據(jù)庫(kù)時(shí)，容易發(fā)生SQL注入。

以烏云公開漏洞wooyun-2016-0175294為例：
客戶端的com.sohu.sohuvideo.provider.PlayHistoryProvider的exported屬性為“true”：

反編譯客戶端，追蹤PlayHistoryProvider的實(shí)現(xiàn)，發(fā)現(xiàn)是用拼接字符串形式構(gòu)造原始的SQL查詢語(yǔ)句：

使用drozer工具，證明漏洞：

對(duì)外暴露的Content Provider實(shí)現(xiàn)了openFile()接口，因此其他有相應(yīng)調(diào)用該Content Provider權(quán)限的應(yīng)用即可調(diào)用Content Provider的openFile()接口進(jìn)行文件數(shù)據(jù)訪問(wèn)。但是如果沒(méi)有進(jìn)行Content Provider訪問(wèn)權(quán)限控制和對(duì)訪問(wèn)的目標(biāo)文件的Uri進(jìn)行有效判斷，攻擊者利用文件目錄遍歷可訪問(wèn)任意可讀文件，更有甚者可以往手機(jī)設(shè)備可寫目錄中寫入任意數(shù)據(jù)。

例子1 以烏云公開漏洞wooyun-2013-044407為例：
此APP實(shí)現(xiàn)中定義了一個(gè)可以訪問(wèn)本地文件的Content Provider組件，為com.ganji.android.jobs.html5.LocalFileContentProvider，因?yàn)槭褂昧薽inSdkServison為“8”，targetSdkVersion=”13”，即此Content Provider采用默認(rèn)的導(dǎo)出配置，即android:exported=”true”：

該P(yáng)rovider實(shí)現(xiàn)了openFile()接口：

通過(guò)此接口可以訪問(wèn)內(nèi)部存儲(chǔ)app_webview目錄下的數(shù)據(jù)，由于后臺(tái)未能對(duì)目標(biāo)文件地址進(jìn)行有效判斷，可以通過(guò)”../”實(shí)現(xiàn)目錄遍歷，實(shí)現(xiàn)對(duì)任意私有數(shù)據(jù)的訪問(wèn)。

例子2
某社交應(yīng)用客戶端，使用了的minSDKVersion為8，定義了私有權(quán)限，并且android:protectionLevel設(shè)為了signature

有一個(gè)對(duì)外暴露的Content Provider，即com.facebook.lite.photo.MediaContentProvider，此Provider沒(méi)有設(shè)置訪問(wèn)權(quán)限，而另外一個(gè)Provider是設(shè)置了訪問(wèn)權(quán)限的：

在MediaContentProvider中實(shí)現(xiàn)了openFile()接口，沒(méi)有對(duì)傳入的URI進(jìn)行限制和過(guò)濾：

此接口本來(lái)只想讓用戶訪問(wèn)照片信息的，但是卻可以突破限制，讀取其他文件：
POC：

讀取到其他文件的內(nèi)容為：

另外看到Openfile()接口的實(shí)現(xiàn)中，如果要訪問(wèn)的文件不存在，就會(huì)創(chuàng)建此文件，還有可能的風(fēng)險(xiǎn)就是在應(yīng)用的目錄中寫入任意文件。

在進(jìn)行APP設(shè)計(jì)時(shí)，要清楚哪些Provider的數(shù)據(jù)是用戶隱私數(shù)據(jù)或者其他重要數(shù)據(jù)，考慮是否要提供給外部應(yīng)用使用，如果不需要提供，則在AndroidManifes文件中將其exported屬性顯式的設(shè)為“false”，這樣就會(huì)減少了很大一部分的攻擊面。
人工排查肯定比較麻煩，建議開發(fā)者使用阿里聚安全提供的安全掃描服務(wù)，在APP上線前進(jìn)行自動(dòng)化的安全掃描，盡早發(fā)現(xiàn)并規(guī)避這樣的風(fēng)險(xiǎn)。

注意：
由于Android組件Content Provider無(wú)法在Android 2.2（即API Level 8）系統(tǒng)上設(shè)為不導(dǎo)出，因此建議聲明最低SDK版本為8以上版本（這已經(jīng)是好幾年前的SDK了，現(xiàn)在一般都會(huì)大于此版本）；
由于API level 在17以下的所有應(yīng)用的“android:exported”屬性默認(rèn)值都為true，因此如果應(yīng)用的Content Provider不必要導(dǎo)出，建議顯式設(shè)置注冊(cè)的Content Provider組件的“android:exported”屬性為false；
如果必須要有數(shù)據(jù)提供給外部應(yīng)用使用，則做好設(shè)計(jì)，做好權(quán)限控制，明確什么樣的外部應(yīng)用可以使用，如對(duì)于本公司的應(yīng)用在權(quán)限定義時(shí)用相同簽名即可，合作方的應(yīng)用檢查其簽名；不過(guò)還是盡量不提供用戶隱私敏感信息。

對(duì)于必須暴露的Provider，如第二部分遇到的風(fēng)險(xiǎn)解決辦法如下：

在AndroidManifest中定義私有權(quán)限的語(yǔ)法為：

其中android:protectionLevel的可選值分別表示：

normal：默認(rèn)值，低風(fēng)險(xiǎn)權(quán)限，在安裝的時(shí)候，系統(tǒng)會(huì)自動(dòng)授予權(quán)限給 application。

dangerous：高風(fēng)險(xiǎn)權(quán)限，如發(fā)短信，打電話，讀寫通訊錄。使用此protectionLevel來(lái)標(biāo)識(shí)用戶可能關(guān)注的一些權(quán)限。Android將會(huì)在安裝程序時(shí)，警示用戶關(guān)于這些權(quán)限的需求，具體的行為可能依據(jù)Android版本或者所安裝的移動(dòng)設(shè)備而有所變化。

signature： 簽名權(quán)限，在其他 app 引用聲明的權(quán)限的時(shí)候，需要保證兩個(gè) app 的簽名一致。這樣系統(tǒng)就會(huì)自動(dòng)授予權(quán)限給第三方

app，而不提示給用戶。 signatureOrSystem：除了具有相同簽名的APP可以訪問(wèn)外，Android系統(tǒng)中的程序有權(quán)限訪問(wèn)。

大部分開放的Provider，是提供給本公司的其他應(yīng)用使用的，一般的話一個(gè)公司打包簽名APP的簽名證書都應(yīng)該是一致的，這種情況下，Provider的android:protectionLevel應(yīng)為設(shè)為“signature”。

注意：一定不要使用拼接來(lái)組裝SQL語(yǔ)句。
如果Content Provider的數(shù)據(jù)源是SQLite數(shù)據(jù)庫(kù)，如果使用拼接字符串的形式組成原始SQL語(yǔ)句執(zhí)行，則會(huì)導(dǎo)致SQL注入。
如下的選擇子句：

如果執(zhí)行此操作，則會(huì)允許用戶將惡意 SQL 串連到 SQL 語(yǔ)句上。
例如，用戶可以為 mUserInput 輸入“nothing; DROP TABLE ** ; ”，這會(huì)生成選擇子句

var = nothing; DROP TABLE **;

由于選擇子句是作為SQL語(yǔ)句處理，因此這可能會(huì)導(dǎo)致提供程序擦除基礎(chǔ) SQLite 數(shù)據(jù)庫(kù)中
的所有表（除非提供程序設(shè)置為可捕獲 SQL 注入嘗試）。

使用參數(shù)化查詢：
要避免此問(wèn)題，可使用一個(gè)“ ? ” 作為可替換參數(shù)的選擇子句以及一個(gè)多帶帶的選擇參數(shù)數(shù)組。
執(zhí)行此操作時(shí)，用戶輸入直接受查詢約束，而不解釋為 SQL 語(yǔ)句的一部分。
由于用戶輸入未作為 SQL 處理，因此無(wú)法注入惡意 SQL。

請(qǐng)使用此選擇子句，而不要使用串連來(lái)包括用戶輸入：

String mSelectionClause = “var = ?”;

按如下所示設(shè)置選擇參數(shù)數(shù)組：

String[] selectionArgs = {“”};

按如下所示將值置于選擇參數(shù)數(shù)組中：

selectionArgs[0] = mUserInput;

還可調(diào)用SQLiteDatabase類中的參數(shù)化查詢query()方法：

1、去除Content Provider中沒(méi)有必要的openFile()接口。
2、過(guò)濾限制跨域訪問(wèn)，對(duì)訪問(wèn)的目標(biāo)文件的路徑進(jìn)行有效判斷：
使用Uri.decode()先對(duì)Content Query Uri進(jìn)行解碼后，再過(guò)濾如可通過(guò)“../”實(shí)現(xiàn)任意可讀文件的訪問(wèn)的Uri字符串，如：

3.4 通過(guò)檢測(cè)簽名來(lái)授權(quán)合作方應(yīng)用訪問(wèn)
如果必須給合作方的APP提供Provider的訪問(wèn)權(quán)限，而合作方的APP簽名證書又于自己公司的不同，可將合作方的APP的簽名哈希值預(yù)埋在提供Provider的APP中，提供Provider的APP要檢查請(qǐng)求訪問(wèn)此Provider的APP的簽名，簽名匹配通過(guò)才讓訪問(wèn)。

[1]《內(nèi)容提供程序基礎(chǔ)知識(shí)
》 https://developer.android.com/guide/topics/providers/content-provider-basics.html
[2]《Android app端的sql注入》http://zone.wooyun.org/content/15097
[3]《Android - Content Providers》 http://www.tutorialspoint.com/android/android_content_providers.htm
[4] http://www.compiletimeerror.com/2013/12/content-provider-in-android.html
[5] https://developer.android.com/guide/topics/manifest/permission-element.html?hl=zh-cn
[6] https://developer.android.com/guide/topics/manifest/permission-element.html
[7] http://www.wooyun.org/bugs/wooyun-2013-039697
[8] http://www.wooyun.org/bugs/wooyun-2014-057590
[9] 《Android Content Provider Security》http://drops.wooyun.org/tips/4314
[10] http://www.wooyun.org/bugs/wooyun-2016-0175294
[11]《Android Content Provider Security
》http://drops.wooyun.org/tips/4314
[12] http://www.wooyun.org/bugs/wooyun-2013-044407
[13] http://www.wooyun.org/bugs/wooyun-2013-044411
[14] 《Content Provider文件目錄遍歷漏洞淺析》，https://jaq.alibaba.com/blog.htm?id=61
[15] https://github.com/programa-stic/security-advisories/tree/master/FacebookLite

作者：伊樵、呆狐@阿里聚安全，更多安全技術(shù)文章，請(qǐng)?jiān)L問(wèn)阿里聚安全博客