Android 安全规约汇总了一些安全工具扫描的规则, Android的安全漏洞以及实际项目中需要注意的安全问题. 并分筛选出市面上加固方案和360火线扫描能够覆盖到的, 和需要手工检查的问题. 具体分布如下表所示.规约可以作为开发时的安全手册, 也可以作为上线前的安全问题checklist.
汇总 | 程序安全 | 基础环境安全 | 数据安全 | 数据传输 |
---|---|---|---|---|
火线覆盖 | 3 | 1 | 4 | 0 |
加固覆盖 | 0 | 4 | 0 | 0 |
手动Check | 4 | 5 | 3 | 2 |
总数 | 7 | 10 | 7 | 2 |
程序安全
组件安全 (火线覆盖)
(强制)禁止导出非必要 Activity | Service | Content Provider组件.
可导出的组件可以被第三方app任意调用,导致敏感信息泄露或者恶意攻击者精心构造攻击载荷达到攻击的目的。在AndroidManifest.xml文件中,我们应该设置设置android:exported属性为false来保护应用。android:exported属性不是唯一的限制措施。我们还可以通过基于权限的方法来定制一个Activity的权限。这个可以限制应用之间的访问权限。
webview 任意代码执行漏洞
(建议) 根据系统版本移除相关方法.
利用android的webView组件中的addJavascriptInterface接口函数,可以实现本地java与js之间交互,在Android 4.2一下版本攻击者可以利用这一点进行远程任意代码执行。另外,android webview组件包含3个隐藏的系统接口:“accessibility”、“accessibilityaversal ”以及“searchBoxJavaBridge_”,同样会造成远程代码执行。
webview 明文保存密码漏洞
(建议) webview中禁止保存密码setSavePassword(false)
在默认情况下,如果用户选择保存在WebView中输入的用户名和密码,则会被明文保存到应用数据目录的databases/webview.db文件中,存在密码被泄露的风险。
webview 域控制不严格漏洞 (火线覆盖)
(建议, 结合组件安全) WebView未禁止访问本地文件系统
如果webview所在组件是可导出的(参考1. 组件安全), 使用webview file域加载本地资源时可被攻击者替换加载污染文件并进行同源策略跨域访问,从而导致隐私信息泄露.
权限管理 (火线覆盖)
(建议) 禁止其他多余的应用功能授权访问此应用,如非必要,自定义权限的保护级别至少要设置为:signature。
自定义权限的保护级别过低,导致任意应用程序都可以使用此权限,无法起到保护作用。
键盘记录
(建议) 需要输入敏感信息时, 使用安全键盘.
木马病毒类程序可以对用户的键盘输入进行记录,从而窃取用户账户、密码等重要信息。建议在输入密码或者其它身份认证信息时调用“自绘随机键盘”,而非系统自带键盘。
屏幕截取
(建议) 在敏感页面设置禁止截屏.
检测应用没有防止屏幕截取功能,攻击者可以通过安装木马在后台偷偷截屏的方式获取用户输入的账号、登录密码,支付密码等信息.
基础环境安全
代码混淆
(强制) 需要混淆代码.
如果不进行代码混淆, 攻击者将dex文件反向成.java文件之后, 就可以看到所有的源码. 通过混淆降低源码的可读性.
dex 保护
(强制) 对dex文件加密处理(加固覆盖).
(建议) 禁止调用不安全路径下dex文件.
SO保护
(建议) 通过修改linker中的dlopen函数等方式禁止第三方调用自己开发的动态链接库.
(建议) 对SO文件进行混淆和加密处理(加固覆盖).
资源文件保护
(建议) 对资源文件进行混淆.
对资源文件进行混淆, 不仅能够起到保护资源文件降低资源文件的可读性, 也可以缩减apk包体积. 推荐使用微信的混淆方案AndResGuard.
模拟器检测
(建议) 禁止App在模拟器运行. 可以参考https://github.com/strazzere/anti-emulator.
模拟器具有经济成本低、高度可定制、易于开发、容易部署等优点,攻击者可以通过自己修改定制特定的模拟器来达到监控应用关键函数、获取应用敏感数据,破解应用的目的。为了增加破解阻力,应用中应该进行模拟器检测,添加反模拟器运行代码。
反编译/重打包 (加固覆盖)
(强制) 反编译保护和二次打包防护
没有作签名校验或者完整性校验,则会使应用程序代码泄漏,面临盗版,被植入广告、恶意代码、病毒等风险。建议对应用进行签名校验,签名信息存储于服务器端。
动态调试 (加固覆盖)
(强制) 设置AndroidManifest.xml配置文件中application属性debuggable为false, 否则应用可以被任意调试,这就为攻击者调试和破解程序提供了极大方便。
备份配置 (火线覆盖)
(强制) 设置AndroidManifest.xml配置文件中application属性allowBackup为false, 否则应用在系统没有root的情况下就可以其私有数据也可以通过备份方式进行任意读取和修改,造成隐私泄露和信息被恶意篡改。
数据安全
敏感日志信息
(强制) 发布应用中禁止包含敏感信息的日志打印.
SharePreference信息存储安全
(建议) 设计敏感信息的key, 命名时需使用缩写或者其他不易知其意的命名。(火线覆盖)
(建议) 加密对应敏感信息.
在使用SharePreference存储用户信息时, 程序应尽可能少的存储用户的敏感数据, 存储的话也应当将例如手机号,密码,token等敏感信息进行加密. 涉及敏感信息的key在命名时也需使用缩写或者其他不易知其意的命名.比如:KEY_PHONENUMBER, KEY_SERVER_IP_ADDRESS,应该改为KEY_P_N, KEY_S_I_A等。
硬编码
(建议) 不要讲加密密钥或一些敏感信息hard code. 可以写入SO, 或者图片中.
将诸如加密密钥之类的存放在应用程序代码中,导致加密算法的破解,给应用开发者和用户造成损失。服务器IP地址硬编码在代码中,造成服务器IP地址暴露,给服务器安全造成威胁。
Content Provider的openFile方法,目录遍历漏洞(火线覆盖)
(强制, 配合组件安全) 复写导出Content Provider的openFile方法时, 需要通过File.getCanonicalPath()方法对路径进行过滤.
如果应用在provider组件导出,且没有做权限限制的情况下,组件重写了ContentProvider.openFile()方法,却没有通过调用File.getCanonicalPath()方法进行过滤路径. 攻击者可以利用该漏洞访问应用沙盒控件中的文件, 存在安全隐患。
Intent.parseUri(), 可能会引发远程拒绝服务、远程提权等攻击(火线覆盖)
(强制, 配合组件安全) 使用Intent.parseUri()时需校验数据来源, 并过滤非法路径.例如通过添加addCategory, setComponent和setSelector设定uri影响范围.
sql注入风险 (火线覆盖)
(强制) 对Content Provider进行增删改查操作时,需要对用户的输入进行过滤,采用参数化查询的方式. 否则可能会导致sql注入攻击.
使用服务端充分校验参数, 使用参数化查询(比如SQLiteStatement), 对用户输入进行过滤等方式, 避免直接使用rawQuery()方法.
数据传输
传输协议
(建议) 使用HTTPS或TCP + SSL等协议传输数据.
使用安全协议来传输数据可以确保数据加密, 校验数据是否被篡改, 并避免域名和会话劫持等安全问题.
证书验证
(建议) 检查服务器证书的有效性.
如果开发者在代码中不检查服务器证书的有效性,或选择接受所有的证书。这种做法可能会导致中间人攻击。
转载请注明出处:http://blog.csdn.net/l2show/article/details/73087501