附录X 译文

分析Android中的应用程序间通信

1. 介绍

在过去的十年里，手机已经从简单的电话和短信设备发展到可以运行第三方软件的仿冒设备。电话拥有者不再局限于简单的通讯簿，如果复印件不是为了利润或商业利益而制作或分发的，并且复印件有附本通知和第一页的完整引文，则允许免费制作本作品的全部或部分数字或硬拷贝供个人或课堂使用。操作系统和电话制造商提供的其他基本功能。他们可以通过安装自己选择的第三方应用程序自由定制手机。移动电话制造商通过提供开发平台和软件商店（如安卓市场、苹果应用商店[1，3]）来支持第三方应用程序开发人员，开发人员可以在这些平台和软件商店分发其应用程序。

Android的应用程序通信模型进一步促进了丰富应用程序的开发。Android开发人员可以利用其他应用程序提供的现有数据和服务，同时仍然给人一种简单、无缝的应用程序的印象。例如，餐厅审查应用程序可以要求其他应用程序显示餐厅的网站，提供餐厅位置的地图，并致电餐厅。这种通信模型减少了开发人员的负担，并促进了功能的重用。Android通过将应用程序划分为组件并提供消息传递系统来实现这一点，以便组件可以在应用程序边界内和跨应用程序边界进行通信。

如果使用不当，Android的消息传递系统可能会成为攻击面。在本文中，我们讨论了Android消息传递的风险，并确定了不安全的开发人员实践。如果消息发送者没有正确地指定接收者，那么攻击者可能会截获消息并破坏其一致性或完整性。如果一个组件不限制谁可以发送它的消息，那么攻击者可以向它注入恶意消息。

我们看到了许多恶意的手机应用程序。例如，短信间谍专业版将自己伪装成一个计算器，并将所有发送和接收的短消息转发给第三方[25]；同样，mo bistealth记录短消息、呼叫历史、浏览器历史记录、GPS位置等[26、4]。这是令人担忧的，因为用户依靠手机来执行私人和敏感的任务，如发送电子邮件、拍照和形成银行交易。因此，帮助开发人员编写安全的应用程序非常重要，这些应用程序不会在对手面前泄漏或更改用户数据。

我们研究Android通信模型及其带来的安全风险，包括个人数据丢失和损坏、网络钓鱼和其他意外行为。我们介绍了Comdroid，一种分析Android应用程序以检测这些漏洞的潜在实例的工具。我们使用Comdroid分析了20个应用程序，在12个应用程序中发现34个漏洞。这些漏洞大多源于这样一个事实：意图可以用于应用程序内部和应用程序间的通信，因此我们提供了更改Android的建议，以帮助开发人员区分内部和外部消息。

2. Android概述

Android的安全模型与标准桌面安全模型有很大区别。Android应用程序被视为相互不信任的主体；它们彼此隔离，彼此无法访问各自的私有数据。接下来，我们将概述Android安全模型和应用程序间通信设施。

虽然其他智能手机平台也有类似的安全模式，但我们将重点放在Android上，因为它拥有最复杂的应用程序通信系统。安卓信息传递系统的复杂性意味着它拥有最大的攻击面。在第6节中，我们将Android与其他移动操作系统进行比较和对比。

2.1 威胁模型

Android市场包含大量第三方应用程序，用户可以安装不同信任级别的应用程序。用户安装来自未知开发人员的应用程序，以及处理私有信息（如财务数据和个人照片）的受信任应用程序。例如，用户可以安装高度信任的银行应用程序和免费的游戏应用程序。游戏不应该能够获取用户的银行帐户信息。

在Android安全模式下，所有应用程序都被视为潜在的恶意应用程序。每个应用程序都以低权限用户ID在自己的进程中运行，默认情况下，应用程序只能访问自己的les。这些隔离机制旨在保护具有敏感信息的应用程序免受恶意软件的攻击。

尽管有默认的隔离，应用程序还是可以选择通过消息传递进行通信。通信可能是一种攻击手段。如果开发人员不小心暴露了功能，那么应用程序可能会被欺骗，从而形成不需要的操作。如果开发人员向错误的接收者发送数据，那么它可能会泄漏敏感数据。在本文中，我们考虑了应用程序如何防止这种基于通信的攻击。

除了提供应用程序间隔离之外，Android安全模型还保护系统API免受恶意应用程序的攻击。默认情况下，应用程序不能与系统API的敏感部分进行交互；但是，用户可以在安装过程中为每个任务额外授予应用程序。我们不考虑对操作系统的攻击；相反，我们专注于保护彼此的应用程序。

2.2 意图

Android提供了一个复杂的消息传递系统，在这个系统中，意图被用来链接应用程序。意图是一条消息，它声明一个接收者，并且可以选择包含数据；意图可以被认为是一个自包含的对象，它指定要调用的远程过程并包含相关的参数。应用程序同时使用应用程序间通信和应用程序间通信的意图。此外，操作系统以事件通知的形式向应用程序发送帐篷。其中一些事件通知是系统范围内的事件，只能由操作系统发送。我们称这些信息为系统广播意图。

意图可以用于明示或暗示的交流。明确的意图指定它应该被传递到由意图指定的特定应用程序，而隐含的意图则要求传递到支持所需操作的任何应用程序。换句话说，一个明确的意图通过名字来识别预期的接收者，而一个隐含的意图则由Android平台来决定哪个应用程序应该接收这个意图。例如，考虑一个存储联系人信息的应用程序。当用户单击联系人的街道地址时，联系人应用程序需要请求另一个应用程序显示该位置的地图。为了实现这一点，Contacts应用程序可以直接向Google地图发送一个明确的意图，或者发送一个隐含的意图，该意图将被传递到任何声称它提供地图Ping功能的应用程序（如Yahoo！）地图或Bing地图）。使用显式意图可以保证将意图传递给预期的接收者，而隐式意图则允许不同应用程序之间的后期运行时绑定。

2.3 组件

意图被传递到应用程序组件，这些组件是逻辑应用程序构建块。android 系统的四种组件：

活动提供用户界面。活动是以意图开始的，它们可以在完成时将数据返回到调用组件。应用程序的所有可见部分都是活动。

服务在后台运行，不与用户交互。下载一个LE或解压缩一个归档文件就是可能在服务中发生的操作的例子。其他组件可以绑定到服务，这样绑定器就可以调用在目标服务接口中声明的方法。意图用于启动和绑定到服务。

广播接收器接收发送到多个应用程序的意图。接受者被收到适当的意图触发，然后在后台运行以处理事件。接收者通常是短命的；他们经常将消息传递给活动或服务。有三种类型的广播意图：正常、粘性和有序。正常广播一次发送到所有注册的接收器，然后消失。有序广播一次传递给一个接收器；而且，在有序广播的传递链中的任何接收器都可以停止其传播。广播接收机能够为接收命令广播设置优先级。粘性广播在取消发送后仍然可以访问，并重新广播给未来的接收器。

内容提供者是可由其应用程序定义的URI寻址的数据库。它们既用于独立的内部数据存储，也用作在应用程序之间共享信息的机制。

意图可以在四个组件中的三个组件之间发送：活动、服务和广播接收器。意图可用于启动活动；启动、停止和绑定服务；以及向广播接收器广播信息。

2.4 组件声明

要接收意图，必须在应用程序清单中声明组件。清单是安装过程中伴随应用程序的配置文件。devel操作程序使用清单指定应将哪些外部意图（如果有）传递到应用程序的组件。

2.4.1 导出组件

要使服务或活动接收意图，必须在清单中取消声明。（广播接收器可以在清单中或运行时声明。）如果组件的声明设置了导出的AG或至少包含一个意图筛选器，则该组件被视为导出的或公共的。导出的组件可以从其他应用程序接收意向，意向L-ters指定应将哪些类型的意向传递到导出的组件。

Android通过将每个意图的ELD与组件的声明相匹配来确定应将哪些意图传递到导出组件。意图可以包括组件名称、操作、数据、类别、额外数据或其任何子集。开发人员通过指定一个收件人组件名来发送一个明确的意图；然后，该意图将以该名称传递给组件。隐式意图缺少组件名称，因此Android使用其他ELD来标识合适的接收者。

意图筛选器可以通过动作、数据和类别来约束传入意图；操作系统将根据这些约束来匹配意图。操作指定要执行的常规操作，数据字段指定要操作的数据类型，类别提供有关要执行的操作的附加信息。例如，编辑图像的组件可能会定义一个意图过滤器，声明它可以接受编辑操作和mime类型为image/*的数据的任何意图。要使组件成为意向的合格接收者，它必须在自己的意向过滤器中指定意向中包含的每个操作、类别和数据。筛选器可以指定比意图更多的操作、数据和类别，但不能少。

多个应用程序可以注册具有相同意图类型的组件。这意味着操作系统需要决定哪个组件应该接收这个意图。广播接收器可以指定一个优先级（作为其意图筛选器的属性），以向操作系统指示组件处理意图的合适程度。当发送命令广播时，具有最高优先级的意向筛选器将收到意向RST。通过要求用户选择首选应用程序（如果用户尚未设置默认选择），可以解决活动之间的联系。服务之间的竞争是通过随机选择服务来决定的。

重要的是要注意，意图筛选器不是安全机制。发送方可以将其想要的任何操作、类型或类别分配给某个意图（只有系统可以发送的某些操作除外），或者可以完全以明确的意图绕过LTER系统。相反，组件可以声明处理任何操作、类型或类别，而不管它实际上是否非常适合所需的操作。

2.4.2 保护

Android通过权限限制对系统API的访问，应用程序必须在其清单中请求每个任务的相应权限，才能访问受保护的API调用。应用程序还可以使用权限来保护自己。应用程序可以通过向清单中组件的声明添加权限要求或为整个应用程序设置默认权限要求来指定调用方必须具有特定权限。此外，开发人员可以在整个代码中添加权限检查。相反，广播意图发送者可以通过要求接收者有一个许可来限制谁可以重新接收意图。（此保护仅适用于广播意图，不适用于活动或服务意图。）应用程序可以使用现有的Android权限或在其清单中定义新权限。

所有权限都有一个保护级别，该级别决定了如何获取权限。有四个保护级别：自动授予常规权限。安装期间，用户可以授予危险权限。如果权限请求被拒绝，则不安装该应用程序。仅当请求应用程序由取消权限的同一开发人员签名时，才授予签名权限。签名权限用于限制组件对开发人员信任和控制的一小部分应用程序的访问。

如果应用程序满足签名要求，或者应用程序安装在系统应用程序文件夹中，则授予SignatureOrSystem权限。来自Android市场的应用程序不能停滞在System Applications文件夹中。系统应用程序必须由设备制造商预先安装或由高级用户手动安装。寻求强保护的应用程序可能需要保留来自更高类别的权限。对于块权限，可以用来禁用设备。由操作定义的签名级别权限，这意味着它只能被授予与操作系统相同的签名（即，用电话制造商的签名签名签名的阳离子），开发人员要在获得许可的情况下保护其组件，然后只有使用该签名的应用程序（如Google制造的应用程序）才能使用与HAT组件相反，使用普通SION保护的组件本质上是不受保护的，因为任何应用程序都很容易获得该权限。

3. 基于意图的攻击面

我们从意图发送者和意图接收者的角度来研究Android通信的安全挑战。在第3.1节中，我们讨论了向错误的应用程序发送意图是如何泄漏用户信息的。数据可以被窃听者窃取，权限可以在应用程序之间被意外地传输。在第3.2节中，我们考虑与接收外部意图相关的漏洞，即来自其他应用程序的意图。如果一个组件意外地公开，那么外部应用程序可以以令人惊讶的方式调用它的组件，或者向其中注入恶意数据。我们在第3.3节中总结了安卓通信安全指南。

在讨论组件安全性的过程中，我们将注意力集中在出口组件上。其他应用程序无法访问未导出的组件，因此不会受到我们在此处提出的攻击。我们还包括导出的组件和广播意图，这些组件和广播意图受其他应用程序无法获取的权限保护。如第2.4.2节所述，正常和危险权限不构成任何组件或意图提供非常强大的保护：自动授予正常权限，通过用户验证授予危险权限。签名和签名系统权限，无论怎样，都是非常难以获得的。我们将使用签名或签名或系统权限保护的组件和广播意图视为私有。

3.1 未授权意向书

当一个应用程序发送一个隐含的意图时，不能保证预期的接收者会收到该意图。恶意应用程序可以简单地通过声明一个意图筛选器来截获一个隐含的意图，该筛选器包含意图中列出的所有操作、数据和类别。然后，合法应用程序可以访问任何匹配意图中的所有数据，除非恶意应用程序所缺少的权限保护了意图。调解还可能导致控制-低攻击，如拒绝服务或网络钓鱼。我们考虑如何在广播接收器、活动和服务的意图上发起攻击。我们还讨论了特殊类型的意图，如果被拦截，这些意图尤其危险。

3.2 意图欺骗

恶意应用程序可以通过向导出的组件发送一个不期望来自该应用程序意图的意图，从而在TACK上启动意图欺骗（图4）。如果被害人申请在收到此类意图后采取某种行动，则攻击会触发该行动。例如，当组件被导出时，即使它不是真正公开的，也可能发生这种攻击。尽管开发人员可以通过在清单中设置权限要求或动态检查调用方的标识来限制组件暴露，但他们并不总是这样做。

3.3 安全通信指南

开发人员应该谨慎地发送隐式的帐篷和导出组件。在发送私有数据时，如果可能，应用程序应该使用显式意图。在内部交流中可以而且应该总是使用明确的意图。如果不能使用显式意图，那么开发人员应该指定强权限来保护意图。其他组件响应意图返回的结果需要验证，以确保它们是来自预期来源的有效结果。

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[442256]，资料为PDF文档或Word文档，PDF文档可免费转换为Word