安全编码技术：定义自主权限问题

在为移动设备开发时，应用程序通常必须向系统请求一些权限。他们可能需要访问用户的联系人、蓝牙连接或发送短信的能力。上面提到的所有权限都是平台权限，由 Android 框架定义。

但是在某些情况下，这些还不够，应用程序需要定义自己的自定义权限。我将以我们自己的公司为例。Secure Code Warrior可能会创建一个应用程序，将一些私人数据保存为个人资料的一部分，包括用户在SCW平台上的表现。如果用户允许另一款安全培训应用程序（例如DevTrainer）使用这些数据，我们希望允许他们使用这些数据。这是敏感数据，用户当然不想让任何人知道这一点，但是SCWApp不应该完全隐藏和保护它，因为它可能很有用。因此，我们希望让用户控制它。这就是自定义权限的用武之地。

SCWApp 创建自定义权限，DevTrainer 请求此权限，用户可以决定是否要允许此权限。这是一种常见的做法，也是限制访问白名单应用程序的好方法。

不幸的是，从安全的角度来看，自定义权限存在一些不直观的行为，这使它们具有风险。任何应用程序都可以随时定义具体的自定义权限，“第一个获胜”，这种策略会带来一些后果。

对于以下场景，我们定义了上面介绍的两个应用程序配置文件（所有这些应用程序都是虚构的，用于演示目的）：

1。 scwApp：定义自定义权限并使用此权限保护组件的应用程序。

2。 开发者训练器：此应用程序定义了与 scwApp 相同的权限，并向用户声明它希望持有此权限。

这是一个常见的场景，被命名为 “同行应用案例”。如果 DevTrainer 应用程序只是 SCWApp 的插件，则不必定义自定义权限。在这种情况下，假设SCWApp将在DevTrainer之前安装，并且不会发生意外行为。如果用户确实以某种方式首先安装了 DevTrainer，则用户不会被告知权限请求。如果用户随后安装了SCWApp，则不会追溯性地授予DevTrainer的权限，因此DevTrainer应用程序尝试使用安全组件将失败。

这就是 Peers 应用案例的用武之地。在某些情况下，你不能指望先安装一个应用程序。比如说，如果Facebook和Twitter都想使用彼此的组件，他们必须定义彼此的自定义权限。

但是，这才是棘手的地方。如果首先安装了 DevTrainer 应用程序，则不会告知用户其自定义权限请求。此时，即使没有通知用户，DevTrainer 仍拥有自定义权限并且可以访问安全组件。

它变得更加棘手了。DevTrainer 应用程序可以更改权限保护级别。Android 不使用防御者的保护级别，而是使用首先定义的保护级别，这意味着无论哪个应用程序最先安装都可以定义它。这意味着，如果 DevTrainer 将权限级别更改为正常，那么任何未来请求此权限的应用程序都无需得到用户的确认，而是会自动获得访问权限。

此场景的灵感来自于对该问题的解释 cwac-安全github。

“先者胜” 策略会带来一些危险的后果，不知道其行为可能会导致开发人员根据不可信的输入做出安全决策，并允许非预期的应用程序访问敏感数据或受保护的服务。要了解有关通过不可信输入避免安全决策的更多信息， 访问我们的平台。自 Android 5.0（Lollipop）起，此行为已更改。但是从目前开始 超过 22% 的 Android 设备仍在运行较低版本的 Android，因此降低应用程序中原始行为的风险非常重要。检查应用程序首次运行时是否已定义权限，如果是这种情况，请采取适当的措施来解决任何安全风险。

祝你编程好运，下周见！

通过定义自定义权限，应用程序可以与其他应用程序共享其资源和功能。

https://developer.android.com/guide/topics/permissions/defining.html