4.4.2 规则书

优质
小牛编辑
134浏览
2023-12-01

4.4.2 规则书

实现或使用服务时,遵循下列规则。

4.4.2.1 仅仅在应用中使用的服务,必须设为私有(必需)

仅在应用(或同一个 UID)中使用的服务必须设置为“私有”。 它避免了应用意外地从其他应用接收意图,并最终防止应用的功能被使用,或应用的行为变得异常。

AndroidManifest.xml中定义服务时,你在必须将导出属性设置为false

AndroidManifest.xml

<!-- Private Service derived from Service class -->
<!-- *** POINT 1 *** Set false for the exported attribute explicitly. -->
<service android:name=".PrivateStartService" android:exported="false"/>

另外,这种情况很少见,但是当服务仅在应用中使用时,不要设置意图过滤器。原因是,由于意图过滤器的特性,可能会意外调用其他应用中的公共服务,虽然你打算调用应用内的私有服务。

AndroidManifest.xml(不推荐)

<!-- Private Service derived from Service class -->
<!-- *** POINT 1 *** Set false for the exported attribute explicitly. -->
<service android:name=".PrivateStartService" android:exported="false">
    <intent-filter>
        <action android:name="org.jssec.android.service.OPEN />
    </intent-filter>
</service>

请参阅“4.4.3.1 导出属性和意图过滤器设置的组合(在服务情况下)”。

4.4.2.2 小心并安全地处理收到的数据(必需)

与“活动”相同,如果是“服务”,则在处理收到的意图数据时,你应该做的第一件事是输入验证。 同样在服务的用户方,有必要验证来自服务的结果信息的安全性。请参阅“4.1.2.5 小心并安全地处理收到的意图(必需)”和“4.1.2.9 小心并安全地处理从被请求活动返回的数据”。

在服务中,你还应该小心实现调用方法,并通过消息交换数据。

请参阅“3.2 小心并安全地处理输入数据”。

4.4.2.3 在验证签名权限由内部定义之后,使用内部定义的签名全新啊(必需)

确保在创建服务时,通过定义内部签名权限来保护你的内部服务。 由于在AndroidManifest.xml文件中定义权限或声明权限请求,没有提供足够的安全性,请务必参考“5.2.1.2 如何使用内部定义的签名权限在内部应用之间进行通信”。

4.4.2.4 不要在onCreate中判断服务是否提供自己的函数(必需)

onCreate中不应包含安全检查,例如意图参数验证,或内部定义的签名权限验证,因为在服务运行期间接收到新请求时,不会执行onCreate过程。 所以,在实现由startService启动的服务时,应该由onStartCommand来执行判断(使用IntentService的情况下,判断应该由onHandleIntent来执行)。在实现由bindService启动的Service的情况下也是一样的,判断应该由onBind执行。

4.4.2.5 返回结果信息,注意来自目标应用的可能的信息泄露(必需)

取决于服务类型,结果信息的目标应用(回调接收方/Message的目标)的可靠性有所不同。 考虑到目标可能是恶意软件的可能性,需要认真考虑信息泄漏。

详细信息请参阅“4.1.2.7 返回结果时,注意目标应用的可能的信息泄露(必需)”。

4.4.2.6 如果目标是固定的,使用显式意图(必需)

当通过隐式意图使用服务时,如果意图过滤器的定义相同,则意图会发送到首先之前的服务。 如果之前安装了恶意软件,它故意定义了同一个意图过滤器,则意图会发送到恶意软件并发生信息泄露。 另一方面,当通过显式意图使用服务时,只有预期的服务会收到意图,所以这样更安全。

还有一些要考虑的要点,请参阅“4.1.2.8 如果目标活动是预定义的,则使用显式意图(必需)”。

4.4.2.7 如果与其他公司的应用链接,验证目标服务(必需)

与其他公司的应用链接时,确保确定了白名单。 你可以通过在应用内保存公司证书的散列副本,并使用目标应用的证书散列来检查它。 这将防止恶意应用伪造意图。 具体实现方法请参考“4.4.1.3 创建/使用伙伴服务”的示例代码部分。

4.4.2.8 当提供二次素材时,素材应该受到相同级别的保护(必需)

当受到权限保护的信息或功能素材,由另一个应用提供时,你需要确保它具有访问素材所需的相同权限。 在 Android OS 权限安全模型中,只有已被授予适当权限的应用,才能直接访问受保护的素材。 但是,存在一个漏洞,因为具有素材权限的应用可以充当代理,并允许非特权应用访问。 基本上这与重新授权相同,因此它被称为“重新授权”问题。 请参阅“5.2.3.4 重新授权问题”。

4.4.2.9 尽可能不要发送敏感信息(推荐)

你不应将敏感信息发送给不受信任的各方。

在与服务交换敏感信息时,你需要考虑信息泄露的风险。 你必须假设,发送到公共服务的意图中的所有数据都可以由恶意第三方获取。 此外,根据实现情况,向伙伴或内部服务发送意图时,也存在各种信息泄露的风险。

首先,不发送敏感数据,是防止信息泄露的唯一完美解决方案,因此你应该尽可能限制发送的敏感信息的数量。 当需要发送敏感信息时,最佳做法是仅发送给可信服务并确保信息不会通过LogCat泄漏。