安全なコーディング手法:カスタム権限の問題

在进行移动开发时，应用程序往往需要向系统申请一些权限。它们可能需要访问用户的联系人、蓝牙连接或发送短信的能力。上面提到的所有权限都是平台权限，由安卓框架定义。

但在有些情况下，这些并不足够，应用程序需要定义他们自己的自定义权限。我以我们公司为例。Secure Code Warrior 可能会创建一个应用程序，将一些私人数据保存为档案的一部分，包括用户在SCW平台上的表现。而我们希望允许另一个安全培训应用，例如DevTrainer，使用这些数据，如果用户允许他们这样做的话。这是敏感数据，用户当然不希望任何人知道这些，但SCWApp不应该完全隐藏和保护它，因为它可能是有用的。所以我们希望让用户对它进行控制。这就是自定义权限的作用。

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

不幸的是，围绕着自定义权限有一些不直观的行为，这使得它们从安全的角度来看是有风险的。具体来说，自定义权限可以由任何应用程序在任何时候定义，而且 "第一个赢"，这种策略会带来一些后果。

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

1. SCWApp：定义自定义权限的应用程序，并使用该权限对组件进行防御。

2.DevTrainer：这个应用程序定义了与SCWApp相同的权限，并向用户声明它希望持有这个权限。

这是一个常见的场景，被称为 "同行应用案例"。如果DevTrainer应用只是SCWApp的一个插件，它就不必定义自定义权限。在这种情况下，假设SCWApp会在DevTrainer之前被安装，不会发生意外的行为。如果用户确实先安装了DevTrainer，那么用户不会被告知请求权限的事情。如果用户后来安装了SCWApp，DevTrainer就不会被追溯性地授予权限，所以DevTrainer应用程序使用安全组件的尝试将会失败。

这就是同行应用案例的意义所在。在某些情况下，你不能期望一个应用程序在另一个之前被安装。比如说，如果Facebook和Twitter都想使用对方的组件，他们必须定义对方的自定义权限。

然而，这就是它变得棘手的地方。如果DevTrainer应用程序首先被安装，用户不会被告知其对自定义权限的请求。在这一点上，即使没有通知用户，DevTrainer也持有自定义权限，可以访问安全组件。

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

这个方案的灵感来自于cwac-security github上对这个问题的解释。

"首战告捷 "的策略有一些危险的后果，不知道它的行为可能会导致开发人员根据不受信任的输入做出安全决策，并允许非预期的应用程序访问敏感数据或受保护的服务。要了解更多关于避免通过不受信任的输入作出安全决定的信息，请访问我们的平台。这种行为从安卓5.0（Lollipop）开始改变。但由于目前有超过22%的安卓设备仍在运行较低版本的安卓系统，因此在你的应用程序中减轻原始行为的风险非常重要。检查该权限是否已经在你的应用程序首次运行时被定义，如果是这样的话，请采取适当的措施来解决任何安全风险。

祝你编码成功，下周见。

通过定义自定义权限，一个应用程序可以与其他应用程序分享其资源和能力。

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