Freebuf：https://www.freebuf.com/articles/compliance/275082.html
0 前言
App系统权限与个人信息紧紧关联，如存储权限-相册/文件、位置权限-地理位置等等，所以做好权限申请的把控也是App安全合规治理中十分重要的部分。下文主要参考TC260-PG-20204A 《网络安全标准实践指南—移动互联网应用程序(App)系统权限申 请使用指南》（下文称为指南）结合了一些国民App中做的比较好的例子进行说明。
本指南依据法律法规和政策标准要求，针对App申请使用系统权限存在的强制、频繁、过度索权，及捆绑授权、私自调用权限上传个人信息、敏感权限滥用等典型问题，给出了App申请使用系统权限的基本原则和安全要求，建议App提供者参考本实践指南规范App系统权限申请和使用行为， 防范因系统权限不当利用造成的个人信息安全风险。——《网络安全标准实践指南—移动互联网应用程序(App)系统权限申 请使用指南》摘要
1 权限申请/使用原则和要求
虽然这部分内容都是《指南》中提到的内容，但是作为权限申请中最重要的部分，还是要拿出来说一下。
1.1.1 权限申请基本原则
1.1.2 权限申请通用要求
下列的通用要求不全，更多详情可以查看指南3 权限申请的原则和要求。
权限申请应满足“最小必要”原则，与业务功能无关的系统权限不向操作系统声明，例如无关的安卓系统权限不在
AndroidManifest.xml（苹果info.plist）文件中声明。注意，未在
AndroidManifest.xml中声明的权限，代码中写了也是没办法进行申请的。(请权限时应同步告知权限申请目的，目的应明确且易于理解，不包含广告及任何欺诈、诱骗、误导用户授权的描述。
不难理解，同步告知就是在申请权限时告知用户获取该权限的目的，如用于拍照、语音等等，目前绝大部分触发场景且一眼能够看到使用目的的权限没有同步弹窗告知其目的，不知后续监管是否会更加严格。
如仅需使用权限组中部分权限，不应在权限声明文件中声明同一权限组其他权限。
应该根据实际场景用到哪个权限就申请哪个，这里涉及到颗粒度问题，后边会具体讨论。
如用户拒绝或撤回授予某服务类型非必要系统权限，App不应强制退出或关闭，且不影响与此权限无关的业务功能使用。
这个不给权限不让用的问题可以说是今年监管检查的重点了，在做合规测试时应该重点检查。
如用户明确拒绝App业务功能所需权限，App不应频繁申请系 统权限干扰用户正常使用，除非由用户主动触发功能，且没有该权限 参与此业务功能无法实现。“频繁”的形式包括但不限于:
单个场景在用户拒绝权限后，48小时内弹窗提示用户打开 系统权限的次数超过1次;
每次重新打开App或使用某一业务功能时，都会向用户索 要或提示用户缺少相关系统权限。
这点做到感觉还是挺难得，不过Android10 11啥的都有不在提示的。可以考虑吧计时加载二次弹窗点击上，不管系统弹窗是否同意都可以满足系统弹窗只谈1次。
除仅用于安全风控场景外，App不应收集不可变更的唯一设备 识别码(如IMEI、MAC地址)。
我们的法务小姐姐来问过几个无用问题，说“MAC是唯一的吗？iOS14不是做了地址随机了吗？”我一时语塞，即使随机也是唯一的，但是通过机改等方式还是可以更改MAC，有什么可纠结的
App应尊重用户的权限设置，不应欺骗或强迫用户同意不必要 的数据访问，若有可能宜为拒绝授权的用户提供替代解决方案。
之前一直认为外卖获取地理位置权限属于必要，但是现在发现elm也可以手动输入地理位置了，这大概也是为拒绝授权的用户提供替代解决方案了吧。
1.2.1 权限使用基本原则
1.2.2 权限使用通用要求
下列的通用要求不全，更多详情可以查看指南4 权限使用的原则和要求。
权限申请获得授权后，App应仅访问满足业务功能需要的最少个人信息。
权限申请后自动采集个人信息的频率应在实现App业务功能 所必需的最低合理频率范围内。
其实关于使用频率问题没有一个统一的标准，在《信息安全技术 移动互联网应用程序（App）个人信息安全测评规范 征求意见稿》附录D中粗略的列了一些场景下的采集频率，但是场景无法穷尽，这个统一标准出起来肯定不容易。
若系统权限申请目的、使用场景发生变化，应重新告知用户。
……
2 关于权限的主要检查点
2.1 检查方法
App权限使用：查看AndroidManifest.xml、Info.plist，最简单的方法把app后缀apk/ipa改成zip然后解压，其他可以用手机助手或者aapt之类的方法。
第三方SDK权限：
通过第三方sdk官网对其sdk权限声明的披露
可以找到官网上的demo下载，查看AndroidManifest.xml文件里声明的权限。
2.2 监管在权限方面的检查
- 是否不给权限不让用
- 是否有频繁获取权限的情况，详情可以查看1.1.2
- 申请敏感权限是否未同步告知目的
- 是否符合targetSDKversion≥23，这块其实大部分都可以满足，重点关注金立渠道。
- 权限触发场景及使用目的等信息是否在隐私政策中的披露
- 权限调用频率的情况，对于频率没有一个标准界定，保证低频即可
- 静默权限调用的情况
3 权限&示例
3.1 区分必要非必要权限——拍视频
必要权限：相机；非必要权限：麦克风
此时未开启麦克风权限应该可以使用拍视频的功能。
3.2 权限获取颗粒度问题
权限组的权限用到哪个申请哪个，不应该全部申请目前来看，除了导航、网约车、运动健康等场景外，其余场景下地理位置权限均不是必要。
举个简单不需要地理位置权限的例子（同城）：
不能存在不给位置权限不能用的情况，需提供给用户自行配置城市的功能，或告知用户会基于IP选择大致对应的城市。
3.3 获取权限目的明示
针对存储和电话权限的获取是否过度以及如何明示获取权限的目的还是很有争议的，比如初始获取存储是为了兼容比较老的插sd卡手机目前绝大部分都可以存储在沙盒区（技术的解释可能存在错误），电话权限一般为了获取imei等信息用于安全风控场景，感觉目的可以大胆写，但是要控制好数据使用。下图为《指南》中对存储及电话权限的
在团体标准T/TAF 078.4-2020《 APP用户权益保护测评规范权限索取行为》中把电话和存储权限去掉了，不过还是严谨的加了等。
4 权限解决方案
4.1 应用权限的最佳做法
谷歌建议避免请求不必要的权限，建议使用基于 intent 的请求。在《指南》中也多次提到使用intent方法，例如使用Intent.ACTION_DIAL通过startActivity拉起系统拨号盘的方式进行拨号、使用MediaStore或SAF框架。
这里有个小插曲，很多非技术的同学可能不理解为什么要唤起系统应用来取代替获取权限，这样可以解决权限问题吗？包括我自己在一开始看到这个形式的时候也是拒绝的，害怕监管机构不了解这种使用方式，但是看到指南里明确写了这种方式，谷歌也是鼓励这种方式。
同样是拍照，为什么使用intent就不用获取权限？举个例子（临时想到这个，也可能不太合适）比如我要从A地去B地：
- 获取系统权限：自己去学个车本，然后买辆车，开过去，我可能中途临时起意去了C地并且要承担出事故的风险。
- 使用intent调取其他应用：我选择让有车有驾驶本的Tom带我去，我没有选择权，但我也不需要承担开车途中的事故风险。
4.2第三方sdk权限严格审查
从公司的近期整改来看，其实由于应用自身获取权限的导致的问题并不多，大部分是第三方SDK对权限获取上的问题。所以还是要建议建立起第三方SDK的审查工作，包括对第三方SDK隐私政策和合规要求的仔细查看，对Demo的检测等等。
此外，这个审查并不是一次结束的，应该是一个长期的工作，每个第三方SDK发生版本变化时就应该重新走一遍审查流程。
今天就先唠到这里，后续如果有想更新的再来更新~