2012年Android应用中的内容泄露与污染漏洞研究

5星 · 超过95%的资源需积分: 9 84 浏览量更新于2024-07-24 收藏 602KB PDF 举报

本文主要探讨了在Android应用程序中发现的两种关键安全漏洞——被动内容泄露（Passive Content Leak）和污染（Pollution）。这些漏洞源于Android应用中的一个未受保护组件——内容提供者(ContentProvider)。内容提供者是Android系统中用于数据共享的重要组件，但如果没有适当的访问控制，就可能导致潜在的安全问题。首先，被动内容泄露指的是恶意应用通过滥用内容提供者的开放权限，无需用户明确许可，就能悄悄地获取应用程序内的私密数据，包括但不限于用户的个人信息、账户信息或敏感配置。这种泄露可能侵犯用户隐私，甚至可能被用于追踪或身份盗窃等非法活动。其次，污染漏洞是指攻击者利用内容提供者的漏洞，意外或故意修改应用程序中的安全设置或配置，从而对系统的正常运行造成严重影响。例如，攻击者可能通过这种手段阻止所有的来电或短信，对用户的生活造成干扰，或者导致系统稳定性下降。为了评估这两种漏洞在实际应用中的普遍性，研究人员在2012年2月收集了62,519个来自不同Android市场的应用程序进行分析。令人担忧的是，结果显示大约有1,279（占2%）的应用存在被动内容泄露的风险，而871（占1.4%）的应用存在污染漏洞。此外，调查还发现其中有435（占0.7%）和39个应用程序同时暴露在这两种威胁之下。这些数据表明，尽管Android平台在不断更新和改进安全机制，但仍有一部分应用程序未能充分保护用户数据和系统安全。开发人员和安全专家需要更加重视对内容提供者及其权限管理的审查，以防止此类漏洞的进一步扩散。用户也需要增强安全意识，谨慎下载和使用来源不明的应用，并定期检查应用程序的权限请求。为了提高整体安全性，建议采取以下措施： 1. 定期更新应用程序和操作系统，确保安装最新版本以修复已知漏洞。 2. 对开发者进行安全培训，强调内容提供者安全的最佳实践。 3. 开发者应限制内容提供者的权限，仅授予完成其功能所必需的数据访问级别。 4. 用户应该只下载信誉良好的应用，并时刻关注权限请求，避免不必要的数据共享。总结来说，这篇论文揭示了Android应用中的严重安全问题，并提供了实用的预防和应对策略，这对于保障用户隐私和系统稳定至关重要。随着移动设备的广泛使用，理解和处理这类漏洞的研究将对整个行业产生深远影响。

1 <?xml version="1.0" encoding="utf-8"?>

2 <manifest xmlns:android="http://schemas.android.com/

3 apk/res/android" package="com.example.app">

4 ...

5 <application ...>

6 <provider

7 android:name=".ExampleProvider"

8 android:authorities="com.example.app.provider"

9 android:permission="com.example.app.permission">

10 </provider>

11 </application>

12 <permission

13 android:protectionLevel="normal"

14 android:name="com.example.app.permission">

15 </permission>

17 </manifest>

Figure 2. An example AndroidManifest.xml

ﬁle that deﬁnes a content provider

Accordingly, to locate those candidate apps, our sys-

tem ﬁrst parses their manifest ﬁles to determine whether

there is any content provider component deﬁned. If yes,

we extract the corresponding attributes. The ﬁrst one is

the exported property as it speciﬁes whether or not the

content provider is accessible by other apps. (If it is not

deﬁned, the default true value is assumed, which means

any app can access it.) The second one is to detect the

presence of any custom permission(s) to regulate the read

or write accesses to the content provider. More speciﬁ-

cally, there are three closely-related ones: readPermission,

writePermission, and permission. The readPermission

and writePermission explicitly specify the respective per-

mission used to query and make changes to the data

managed by content provider. If they are missing, the

permission attribute will be used.

In other words, our system chooses those apps as candi-

dates if they explicitly export a content provider by setting

true in its exported attribute or implicitly export this in-

terface without specifying this attribute. In addition, our

system also selects those apps, which may have custom

permissions, but the corresponding protection level(s) are

not deﬁned or deﬁned at the normal level. After that, for

bookkeeping purposes, we further extract other attributes of

the content provider component from these candidate apps,

including the name property, which speciﬁes the speciﬁc

class implementing the content provider interface, as well as

authorities, which is used by the Android runtime to lo-

cate the content provider itself. All these relevant attributes

will be collected along with the app information and saved

into a local database for subsequent analysis.

3.2 Vulnerable App Determination

After selecting candidate apps, our next step is to ana-

lyze them to locate vulnerable ones. In order to effectively

manage a structured set of data in a local SQLite database,

the Android framework provides well-deﬁned APIs to ease

the creation and maintenance of content providers. Specif-

ically, these APIs are provided in a number of system-

wide classes, including SQLiteDatabase (which contains

the methods to create, delete and execute SQL commands)

and SQLiteQueryBuilder (which helps build SQL queries).

In other words, content providers can leverage these meth-

ods to implement their own standardized APIs that can

be invoked to query and make changes to records in lo-

cal databases. To simplify our discussion, we call these

Android APIs that actually manipulate local databases

terminal functions.

From another perspective, the content provider compo-

nent essentially encapsulates local content and exports them

through standardized APIs. For instance, one standard-

ized API is query() that accepts one parameter URI to pin-

point which table to query and other parameters to spec-

ify query conditions (e.g., the conditions used in the where

clause). Another API is insert() which handles requests

to insert new content into local databases. Consequently,

these Android APIs become the actual entry points of con-

tent providers to other apps. We call them start functions.

Figure 3 shows the implementation of a content provider

named ExampleProvider. It implements the query() (line

17), insert() (line 29) and openFile() (line 37) inter-

faces which can be invoked by other apps to operate on

the internal SQLite database and internal ﬁles. Hence these

three functions are start functions. In order to manipu-

late the data maintained by the internal SQLite database, it

leverages the methods provided by SQLiteDatabase class

to perform SQL query (line 25) or insert data (line 33) into

database. Hence these two methods are terminal functions.

Similarly, the function used to open internal ﬁles (line 41)

is classed as a terminal function.

A passive content leak vulnerability exhibits if certain

inputs can trigger an execution path from a start function

to a terminal function. Accordingly, we generate a func-

tion call graph of a given app to help determine reachabil-

ity from the public content provider interfaces (i.e., start

functions) to the low-level database-operating routines (i.e.,

terminal functions). More speciﬁcally, we ﬁrst generate

the whole program function call graph for the app and ﬁnd

all the functions containing terminal functions. Then for

each start function, we identify all potential paths from

it to corresponding terminal functions. Although the con-

struction of whole program function call graph is a well-

studied topic, there are certain aspects unique to Android.

One example is the resolution of object references, which is

the Android counterpart to traditional points-to analysis in

binary analysis, as the exact type of a class object needs to

be determined before we can actually obtain the list of func-

tions it may invoke. The second one is the call graph dis-

continuity introduced by the event-driven nature of Android

apps (e.g., with extensive use of callbacks or event registra-

tions). As an app may register various callback functions

剩余15页未读，继续阅读

君的名字

粉丝: 7w+
资源: 19

2012年Android应用中的内容泄露与污染漏洞研究

wx494社区门诊管理系统小程序-php+vue+uniapp.zip（可运行源码+sql文件+文档）

MongoDB在Linux上的深度探索：安装、操作、可视化及实验指南.pdf

wx364校园约拍小程序-ssm+vue+uniapp.zip（可运行源码+sql文件+文档）

write about 6-7 sensors, description about sensors

acc gyro mag

[2]《Detecting the overlapping and hieerarchical community structure in complex networks》

abnormally detection paper

color sensor

using python how to write a code for detecting cat in a picture

sar sensor有什么作用

最新资源