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泄漏。