【缺陷周话】第56期：ContentProvider URI 注入

 

1、ContentProvider URI 注入

ContentProvider 作为 Android 的四大组件之一，常常用来为不同的应用之间数据共享提供统一的接口。在Android系统中各应用的数据是对外隔离的，如果想要访问其它应用的部分数据就需要 ContentProvider，例如应用访问联系人这个功能就用到了 ContentProvider。ContentProvider 的使用类似于数据库的操作，它拥有增删改查的操作，同样的 ContentProvider也具有被注入的风险。构建含有用户输入的 ContentProvider 查询指令会让攻击者能够访问未经授权的内容或者动态构造一个 ContentProvider 查询 URI，造成字符串查询注入。本文以JAVA语言源代码为例，分析“ContentProvider URI 注入”缺陷产生的原因以及修复方法。该缺陷的详细介绍请参见CWE ID  89: ImproperNeutralization of Special Elements used in an SQL Command (‘SQL Injection’)(http://cwe.mitre.org/data/definitions/89.html)。

 

2、“ContentProvider URI 注入”的危害

ContentProvider URI 注入通常情况下会造成信息缺失和恶意访问应用数据。

从2019年1月至2019年10月，CVE中共有1条漏洞信息与其相关。漏洞如下：

CVE编号	漏洞概述
CVE-2019-14339	适用于 Android 的 Canon PRINT jp.co.canon.bsd.ad.pixmaprint 2.5.5 应用程序中的 ContentProvider 不能正确限制 canon.ij.printer.capability.data 数据访问。这使攻击者的恶意应用程序可以获得敏感信息，包括管理员Web 界面的出厂密码和 WPA2-PSK 密钥。

 

3、示例代码

3.1 缺陷代码

上述代码操作是获取 EditText 接收到的值作为URI构造 ContentProvider 查询语句。首先第18行 Activity 加载布局文件，第19行通过 findViewById() 方法找到布局文件中对应的 EditText 控件，第20行获取 et 这个文本输入框的值。第21行调用 Uri.parse() 方法返回的是一个 URI 类型，通过这个URI可以访问一个网络或者是本地的资源。第22行调用 getContentResolver() 方法会返回一个 ContentResolver 对象，这个对象是内容解析器，Android中程序间数据的共享是通过 Provider/Resolver 进行的。提供内容的就叫Provider，Resovler 提供接口对提供的内容进行解读。返回的对象调用query() 方法来按照用户输入的内容进行查询。假定应用程序提供了多个URI作为 ContentProvider 的入口，如 “content://my.authority/messages” 和 “content://my.authority/messages/test”。

在上述代码片段中，程序中未校验用户输入的内容，并且程序动态构建查询 URI 拼接字符串。攻击者可以通过向 msgId 代码提供值 deleted 调用 content://my.authority/messages/deleted 来改变查询的意义。

使用代码卫士对上述示例代码进行检测，可以检出“ContentProvider URI 注入”缺陷，显示等级为高，从跟踪路径中可以分析出数据的污染源以及数据流向。在代码行第22报出缺陷，如图1所示：

图1：“ContentProvider URI 注入”检测示例

3.2 修复代码

在上述修复代码中，在第21行使用 Uri.encode() 方法对接收的 URI 进行编码，该方法使用 UTF-8 编码集将给定字符串中的部分字符进行编码，编码可以有效避免特殊字符参与程序语句构造造成的程序歧义，这种歧义会导致注入的发生。

使用代码卫士对修复后的代码进行检测，可以看到已不存在“ContentProvider URI 注入”缺陷。如图2所示：

图2：修复后检测结果

 

4、如何避免“ContentProvider URI 注入”

阻止注入攻击的最佳做法是采用一些间接手段。例如创建一份合法资源名的列表，并且规定用户只能选择其中的资源名。使用这种方法，用户不能直接指定资源名称。在某些情况下，这种方法并不可行，因为这样一份合法资源名的列表过于庞大，难以跟踪。因此，通常在这种情况下也可以采用黑名单的办法。在输入之前，黑名单会有选择地拒绝或避免潜在的危险字符。但是，不完整的黑名单仍有可能出现纰漏。相对于以上两种方式，更好的方法是创建一份白名单，允许其中的字符出现在资源名称中，且只接受完全由这些被认可的字符组成的输入。