今天总结Android APP四大组件中Content Provider挖掘的知识，主要分为两个部分，一部分是对Android Content Provider内容提供器的原理总结，另一部分便是对Android provider机制常见的一些漏洞总结，包括一些已知的漏洞方法，和一部分案例实践。

Content Provider可以使得不同APP进程之间进行数据交互和共享，即跨进程通信

我们创建一个Content Provider，其他的应用可以通过使用ContentResolver来访问ContentProvider提供的数据，而ContentResolver通过uri来定位自己要访问的数据，所以我们要先了解URI

URI的介绍：

构建URI的路径：

URI各部分的获取：

我们给出一个URI的样例：

我们介意使用一些方法来获取URI的各个部分：

MIME是指定某个扩展名的文件用一种应用程序打开，就像用浏览器查看PDF格式的文件，浏览器会选择合适的应用打开。ContentProvider 会根据 URI 来返回 MIME 类型，ContentProvider 会返回一个包含两部分的字符串。MIME 类型一般包含两部分，如：

分为类型和子类型，Android 遵循类似的约定来定义MIME类型，每个内容类型的 Android MIME 类型有两种形式：多条记录（集合）和单条记录。

vnd 表示这些类型和子类型具有非标准的、供应商特定的形式。Android中类型已经固定好了，不能更改，只能区别是集合还是单条具体记录，子类型可以按照格式自己填写，在使用 Intent 时，会用到 MIME，根据 Mimetype 打开符合条件的活动。

这里URI代表要操作的数据，我们在对数据进行获取时需要解析URI，Android提供了两个操作URI的工具类：UriMatcher 和 ContentUris

UriMatcher：

UriMatcher类用于匹配Uri，使用步骤如下：

此处采用 addURI 注册了两个需要用到的 URI；注意，添加第二个 URI 时，路径后面的 id 采用了通配符形式 “#”，表示只要前面三个部分都匹配上了就 OK

补充：

ContentUris:

ContentUris类用于操作Uri路径后面的ID部分，有两个比较实用的方法：withAppendedId(Uri uri, long id)和parseId(Uri uri)

ContentProvider是一个抽象类，我们需要开发自己的内容提供者就需要继承这个类并复写其方法：

如果操作的数据属于集合类型，那么 MIME 类型字符串应该以 vnd.android.cursor.dir/ 开头：

如果要操作的数据属于非集合类型数据，那么 MIME 类型字符串应该以 vnd.android.cursor.item/ 开头：

当外部应用需要对ContentProvider中的数据进行添加、删除、修改及查询操作时，可以使用ContentResolver类来完成，要获取ContentResolver对象，可以使用Activity提供getContentResolver()

ContentResolver类提供了与ContentProvider类相同签名的四个方法：

这些方法的第一个参数为Uri，代表要操作的ContentProvider和对其中的什么数据进行操作，其实和ContentProvider里面的方法是一样的，最终会被传到我们之前程序里面定义的ContentProvider方法。

使用ContentResolver对ContentProvider中的数据进行操作：

监听数据变化：

如果ContentProvider的访问者需要知道数据发生的变化，可以在ContentProvider发生数据变化时调用getContentResolver().notifyChange(uri, null)来通知注册在此URI上的访问者。只给出类中监听部分的代码：

而访问者必须使用ContentObserver对数据（数据采用uri描述）进行监听，当监听到数据变化通知时，系统就会调用ContentObserver的onChange()方法：

创建内容提供者的基本流程：

Content Provoder漏洞大致可以分为：

Content Provider漏洞的危害：

先检测组件的exported属性，再检测组件permission、readPermission、writePermissio对应的protectionlevel，最后再检测sdk版本

如上，可以拼接出：

我们下面将结合这三种方法来对一些常见的案例进行漏洞挖掘介绍

案例1：盛大有你Android存在信息泄露漏洞

目标代码：

攻击代码：

代码分析：

我们可以分析目标程序的provider的进程名和授权的的URI，我们可以根据授权的URI来构建一个URI，然后通过contentresolver去读取里面的的列表名信息，这样我们就可以获取APP中的隐私数据信息。

案例2：样例sieve.apk

我们先向apk中添加一条数据，然后保存：

我们先使用drozer对内容提供器的路径进行扫描：

报错：drozer could not find or compile a required extension library

这是由于我们drozer2.7中代码导致的，我们需要修改相应的代码，参考网址(https://github.com/FSecureLABS/drozer/issues/361 )

我们可以对敏感数据读取：

我们就成功的将我们刚才保存的账号密码信息给获取了

案例3：CVE-2018-9546: Download Provider文件头信息泄露

漏洞描述：

目标代码：

攻击代码：

由于header的URI并未做一些防护措施，我们可以将download_id取具体的值，然后来获取里面的具体信息

案例1：安全管家客户端存在SQL注入攻击

漏洞说明：

Androidmanifest文件中定义的provider：

使用drozer扫描客户端程序存在的contentProvider uri:

搜索到对外暴露可访问的uri:

newapp.db结构：

查看新安装应用的包名：

查看白名单：

案例2：样本sieve

我们使用drozer扫描注入的位置：

然后我们执行以下命令，发现返回了报错信息，接着构造sql获取敏感数据

列出所有表信息：

获取具体表信息

列出该app的表信息

案例3：CVE-2018-9493: Download Provider SQL注入

漏洞分析：

目标代码：

攻击代码：

详细可以参考该作者博客：(https://mabin004.github.io/2019/04/15/Android-Download-Provider%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90/)

漏洞触发的前提条件：

案例1：赶集网Android客户端Content Provider组件任意文件读取漏洞

漏洞分析：

攻击代码：

案例2：样本sieve

我们检测文件遍历漏洞：

我们读取系统文件：

我们下载系统文件：

案例3：

目标代码：

我们可以从目标代码中分析，这段代码使用android.net.Uri.getLastPathSegment()从paramUri中获取文件名，然后将其放置在预定义好的目录IMAGE_DIRECTORY中，如果该URL是encoded编码后的，那么将可能导致目录遍历漏洞

Android4.3开始，Uri.getLastPathSegment()内部实现调用Uri.getPathSegments()

Uri.getPathSegments首先会通过getEncoded()获取一个路径，然后以”/“为分隔符将path分成片段，最后调用decode()方法解码

假如我们传递encoded编码后的url给getLastPathSegment()，编码后的分隔符就变成了%2F,绕过了内部的分割规则，那么返回的就可能不是真正想要的文件了。这是API设计方面的问题，直接导致了目录遍历漏洞

为了避免这种情况导致的目录遍历漏洞，开发者应该在传递给getLastPathSegment()之前解码，采用调用两次getLastPathSegment()方法的方式，第一次调用是为了解码，第二次调用期望得到正确的值这一部分大家可以详细参考博客：(https://tea9.xyz/post/758430476.html)

本文对Content Provider内容提供器的基本原理做了一个详细讲解，然后对Provider常见的一些漏洞情况作了分析，这里面一部分漏洞来自于漏洞平台，一部分来自于网上的博客收集总结，还提供了一个样例sieve.apk，初步的实现信息泄露、SQL注入、目录遍历漏洞的基本操作方式，也介绍了一般挖掘provider漏洞的基本方法，其中关于drozer的具体操作使用，大家可以参考之前的博客：Android漏洞挖掘三板斧——drozer+Inspeckage(Xposed)+MobSF，当然可能对于Provider中的漏洞介绍还不是很全面，其他的就请各位大佬指正了。
github首页：github

Content Provider原理介绍

Content Provider漏洞挖掘

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！