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

阅读量748068

发布时间 : 2019-10-21 17:15:45

 

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 注入”

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

本文由奇安信代码卫士原创发布

转载,请参考转载声明,注明出处: https://www.anquanke.com/post/id/189173

安全客 - 有思想的安全新媒体

分享到:微信
+10赞
收藏
奇安信代码卫士
分享到:微信

发表评论

奇安信代码卫士

奇安信代码卫士是国内第一家专注于软件开发安全的产品线,产品涵盖代码安全缺陷检测、软件编码合规检测、开源组件溯源检测三大方向,分别解决软件开发过程中的安全缺陷和漏洞问题、编码合规性问题、开源组件安全管控问题。微信公号:codesafe。

  • 文章
  • 387
  • 粉丝
  • 104

热门推荐

内容需知
  • 投稿须知
  • 转载须知
  • 官网QQ群8:819797106
  • 官网QQ群3:830462644(已满)
  • 官网QQ群2:814450983(已满)
  • 官网QQ群1:702511263(已满)
合作单位
  • 安全客
  • 安全客
Copyright © 北京奇虎科技有限公司 360网络攻防实验室 安全客 All Rights Reserved 京ICP备08010314号-66