导语
根据谷歌最新发布的Android安全公告,2018年八月Android安全补丁将解决了多个最为严重的安全漏洞,包括允许本地恶意程序绕过用户交互请求来获取其他访问权限,和让远程攻击者执行任意代码bug。
目录
1、组件
2、WebView
3、存储
4、传输
5、日志
6、防止二次打包和动态调试
7、漏洞检测工具
8、Android P 安全防护新特性
组件
1). 设置权限开放属性android:exported=["false"]
Activity:表示是否允许外部应用组件启动。
Service:表示是否允许外部应用组件调用服务或与其进行交互。
Receiver:表示是否可以接收来自其应用程序之外的消息。
Provider:表示是否允许其他应用程序访问内容提供器。
设置为“false”后,组件只能由同一应用或同一用户 ID 的不同应用启动,大大加强安全性。
2). 配置自定义权限
定义:
...
暴露:
...
...
使用:
在manifest文件中申请该权限,该权限的使用和Android提供的权限的使用是一样的,均为使用uses-permission标签
3). LocalBroadcastManager
区别基于Binder实现的BroadcastReceiver,LocalBroadcastManager是基于Handler实现的,拥有更高的效率与安全性。主要体现在数据仅限于应用内部传输,避免广播被拦截、伪造、篡改的风险。
4). Application相关属性配置
- debugable属性 android:debuggable="false"
根据官方文档说明,默认值就是false,一般不用手动配置。 - allowBackup属性 android:allowBackup= "false"
设置是否支持备份,默认值为true,应当手动配置为“false”,避免应用内数据通过备份造成的泄漏问题。
5). intent 安全问题
- 隐式intent没有明确指明哪些接收方有权限接收,恶意程序指定action标识后,可以获取intent内容,导致数据泄漏、intent劫持、仿冒、钓鱼应用等风险使用。
- 隐式调用建议使用Intent.setPackage、Intent.setComponent、Intent.setClassName、Intent.setClass四种方法中任一种明确指定目标组件名称。
WebView安全
1). 处理不校验证书漏洞:继承WebViewClient重写onReceivedSslError时SslErrorHandler.cancel();
2). 处理file协议安全漏洞:
setAllowFileAccess(false); setAllowFileAccessFromFileURLs(false);
setAllowUniversalAccessFromFileURLs(false);
3). 处理file协议安全漏洞:
WebSettings.setSavePassword(false)
4).开启安全浏览模式:
...
数据存储安全
1). 秘钥及敏感信息
项目中经常用AES对数据进行加解密,并将密钥直接写在项目文件中,这样做会有一定的风险。此类配置应当妥善存放,不要在类中硬编码敏感信息,因此可以使用JNI将敏感信息写到Native层。为了防止二次打包debug出密钥,我们可以采取验证apk签名的方式校验。
2). SharePreferences
首先不应当使用SharePreferences来存放敏感信息。存储一些配置信息时也要配置好访问权限,如私有的访问权限 MODE_PRIVATE,避免配置信息被篡改。
3). 签名配置signingConfigs
避免明文保存签名密码,可以将密码保存到本地,无需上传版本控制系统
数据传输安全
1). 使用HTTPS协议
不要在类中硬编码敏感信息,可以使用JNI将敏感信息写到Native层。
2). SSL通信服务端检测信任任意证书
自定义SSL x509 TrustManager重写checkServerTrusted方法,方法内严格判断服务端和客户端证书校验,对于异常事件禁止return 空或者null,防止黑客可以使用中间人攻击获取加密内容。
3). Android N 包含一个网络安全配置特性,让应用可以在一个安全的声明性配置文件中自定义其网络安全设置,而无需修改应用代码,只需要以 PEM 或 DER 格式将自签署或非公共 CA 证书添加到 res/raw/my_ca。
在AndroidManifest.xml中配置:
...
network_security_config文件如下:
example.com
日志输出
日志是我们开发调试中不可或缺的一部分,但也是最容易泄露敏感信息的地方。所以,在我们发布应用时,应当关闭、甚至移除Log输出:
if (BuildConfig.DEBUG == true) {
Log.e(tag, msg);
}
防止二次打包和动态调试
1). 混淆代码,可以增加反编译破解的难度。但是我们在使用混淆功能时也要注意实体类、与JS交互的方法、第三方混淆配置等问题。
2). 应用加固也是近年来比较热门的应用安全解决方案,各大厂商都有自己的加固方案,常见的如腾讯乐固、360加固、梆梆加固等等。
3). Native层增加签名校验,当发现apk签名和我们自己的签名不一致的时候,调用so库直接崩溃即可。
4). 获取MANIFEST.MF文件中的classes.dex文件的SHA-1哈希值,通过后台保存的初始值进行校验。
5). java层代码中验证签名,这种纯粹的字符比较都很容易破解掉。
6). 通过api和ApplicationInfo的flag判断是否调试状态,碰到调试器动态调试即可果断结束程序(打正式包时开启此逻辑)
漏洞检测工具
当项目代码量庞大以后,积累了较多的历史代码,人工检测代码工作量大。这时,漏洞检查工具就派上用场了,比较出名的有AndroBugs、YSO-Mobile Security Framework、FindBugs + FindSecurityBugs,而中文的漏洞检测工具中比较有名的就是360的FireLine。
FireLine介绍
优势:
1). 免费提供静态代码扫描服务
2). 用户本机执行,不收集任何数据
3). Studio中搜索plugins安装
4). 扫描速度快
5). 中文描述扫描规则:
1). APP安全检查
2). 代码规范检查
3). 内存泄露检查
4). 日志输出检查
5). 空指针检查
6). 多线程检查-
FireLine配置和运行
-
扫描完成后,在火线报告输出路径找到testReport.html,打开后可见,会看到列出你项目中存在的问题
-
圆形加好按钮,点开就可展开显示问题存在代码中的位置
Android P 安全防护新特性
1). 统一身份验证对话框
生物传感器被广泛应用于身份认证,为了保障用户在不同感应器和应用间能够获得一致的体验 Android9操作。应用不再需要自行设计对话框,而是通过调用BiometricPrompt API触发系统对话框。除指纹识别以外(包括屏幕下指纹识别),该API还支持面部识别以及虹膜识别。
2). 高可信度用户确认
Android 9 新增了高可信度用户确认 (Android Protected Confirmation) ,该功能通过可信执行环境 (TEE) 确保提示文本被真实用户确认。只有在用户成功确认之后,TEE 才会签发该文本,该环境会对显示的确认对话框以及用户输入进行保护。
借助这个新增的 API,应用可以利用 ConfirmationDialog 的实例向用户显示提示,请他们批准一个简短的声明。 应用可以通过这个声明再次确认,用户确实想完成一项敏感事务,例如付款。
3). 加强密钥安全保护
加入了一个新的 KeyStore 类 —— StrongBox,并提供相应的 API 来支持安装了 Android P 的受支持设备,该实现位于一个硬件安全性模块内,其中包含了自己的 CPU、安全存储空间、真实随机数生成器以及抵御软件包篡改和未经授权线刷应用的附加机制。 检查存储在 StrongBox Keymaster 中的密钥时,系统会通过可信执行环境 (TEE) 证实密钥的完整性。支持以下算法和密钥长度:
RSA 2048
AES 128 和 256
ECDSA P-256
HMAC-SHA256 (支持 8-64 字节密钥长度,含首末值)
Triple DES 168
4). DNS over TLS
Android 9 内置对 DNS over TLS 的支持:若网络 DNS 服务器提供支持,设备会自动将 DNS 查询升级为 TLS 查询。用户可以通过更改 “网络和互联网” 设置下的隐私 DNS (Private DNS) 模式来管理 DNS over TLS 行为。自行运行 DNS 查询的应用可以通过调用新的 LinkProperties.isPrivateDnsActive() API 来获取 DNS 模式相关信息。
5). 默认使用 HTTPS
为了将所有网络流量从明文 (未加密的HTTP) 逐步迁移至 TLS,更改了网络安全配置的默认设置,以阻止所有明文流量,强制应用通过 TLS 建立网降连接,除非开发者明确允许特定域名使用明文传输。
6). 用户隐私
系统禁止所有处于空闲状态的应用对话筒、摄像头和所有 SensorManager 传感器的访问。
当应用的 UID 空闲时,麦克风将会报告 “无音频信号”,传感器将会停止报告事件,应用使用的摄像头也会断开连接,并在应用试图访问时生成错误。
在大多数情况下,这些限制不会对现有应用造成新的问题,但建议从应用中移除此类传感器请求。