之前在app中并未涉及支付,敏感信息等相关功能的模块,所以对于安全这块的话并没有进行十分严格的控制。但是随着检查的一步步变的严格,各种检验报告接踵而至,“不安全”你们的app,马上改,不改立马下架(公司为某央企媒体类,检查委托机构是公安部,被委托检查机构好几个出了好几份报告)。
所以总结一下,为以后开发或者设计产品时候提供安全规范。
下面涉及的安全问题均来自于我们的app的安全检测报告,具有实际参考价值。可能不够全面但是囊获了大部分的安全问题
。
app包的破解反编译问题是最危险也是最基础的问题。细分的话有:
Activity劫持问题(伪造登录页面,支付页面)也就是钓鱼页面问题;
app被重新打包动态调试问题;
广告插入风险;
防二次打包;
app本地存储文件涉及敏感信息的要做加密处理。例如,file,sharepreference,Sqlite等;存储数据包含用户名,密码,支付相关信息等等。
首先,传输协议安全问题。其次,敏感信息(密码,支付相关信息等)拦截安全问题。
登录接口未做错误次数限制等。
短信接口存在缺陷,攻击者可滥用此接口进行短信轰炸。
后端可添加重试次数以及IP地址等限制。
安全问题不可能百分之百的得到解决,从理论上是不可能的。但是破解方也会从利益的角度来考虑破解或者叫攻击一个app或者网站是不是值得,如果花的力气比得到的利益多我感觉即使得手了也是赔本的,这些人不会做这样的事情。所以只要我们把安全问题中的绝大部分问题解决了或者加大破解攻击难度,我们的app安全就能得到保证。下面是上面问题的解决方案,注意随着时间的推移攻防两端都在进步那么解决方案也会不断的优化,所以我们也要不断关注安全技术的迭代。
apk包的防止反编译和防止被二次打包是最基础和最有效的防止安全问题产生的方式。代码的泄漏,动态调试,广告的植入,钓鱼页面等问题都能基本上得到解决。
相应的方案就是:
1.代码混淆
2.使用比较靠谱的第三方加固
工具,例如360,百度,腾讯,爱加密等等。具体的使用方法去相应的官网看文档就行了,会比较容易,因为是提供服务的难了没人用。这里不展开介绍各个平台的具体流程因为它们会不断迭代,相应的处理方法等可能会有变化,所以只要去它们官网查看最新的使用方法就好了。
在AndroidStudio中实现代码压缩和混淆,通过Gradle构建工具来实现。由于Gradle的强大我们可以实现对“不同情况”采取不同的混淆策略
。而真正起作用的工具是ProGuard,下面介绍概念和使用方法。
ProGuard :非常重要的一个工具主要提供了两个功能,一个是“代码压缩”;另一个是“代码的混淆”
。关于其作用的介绍在官网的说明如下:
同时奉上官网介绍Proguard链接
android {
...省略代码...
buildTypes {
...省略代码...
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'),
'proguard-rules.pro'
}
}
...省略代码...
}
1.proguard-android.txt文件是默认的压缩和混淆规则设置文件
;同时要想做进一步的代码压缩,请尝试使用位于同一位置的 proguard-android-optimize.txt 文件。它包括相同的 ProGuard 规则,但还包括其他在字节码一级(方法内和方法间)执行分析的优化,以进一步减小 APK 大小和帮助提高其运行速度。
2.proguard-rules.pro 文件用于添加自定义 ProGuard 规则
。默认情况下,该文件位于模块根目录(build.gradle 文件旁)。
官方的说法如下:
想让每个渠道中添加各自渠道特有的压缩和混淆策略,也就是拥有“默认的”和“统一自定义的”和“各个渠道独有的”
三种压缩和混淆策略的并集。
在相应的 productFlavor 代码块中再添加一个 proguardFiles 属性。如下面是我的要打包的各个渠道:
productFlavors {
...省略代码...
Umeng {proguardFile 'umeng-rules.pro'}
wandoujia {proguardFile 'wandoujia-rules.pro'}
...省略代码...
}
umeng-rules.pro和wandoujia-rules.pro是我们创建的各个渠道对应的规则文件,存放在和proguard-rules.pro相同的文件夹中。如下图
我们在开发过程中绝大部分情况下,只需要编写proguard-rules.pro文件就可以了。因为想要对不同渠道包应用压缩混淆策略的情况极少
。
一旦minifyEnabled true了那么就开启了代码压缩和混淆。那么就面临两种问题的出现,如下
1.系统误认为没有用到类,方法等直接被删除了;
2.系统认为用到了,但是进行了混淆处理(将包名,类名,方法名变成了单个字母);
为了解决上面的问题混淆文件配置就应运而生。文件中配置的内容就是解决上面的问题:声明我们想要保留的类,方法。
对于某些情况,默认 ProGuard 配置文件 (proguard-android.txt) 足以满足需要,ProGuard 会移除所有(并且只会移除)未使用的代码。不过,ProGuard 难以对许多情况进行正确分析,可能会移除应用真正需要的代码。举例来说,它可能错误移除代码的情况包括:
当应用引用的类只来自 AndroidManifest.xml 文件时
当应用调用的方法来自 Java 原生接口 (JNI) 时
当应用在运行时(例如使用反射或自检)操作代码时
由于一些信息要存储在手机本地,那么相应的敏感信息就要进行加密处理,不然很容易泄漏出去。
##数据加密选择
###4.1File或SharePreference缓存加密
如果app有本地缓存功能并且缓存的内容比较重要,那么就要对缓存内容加密。一般我们使用file或者sharepreference进行Json的缓存,对于想要加密的Json进行相应的加密就行了。这里我们可以全部加密,也可以有选择的加密(例如我之前的公司是做保险类CRM类型app的里面好多的用户信息和工作人员信息,我们用的全部加密方式)。
关于使用什么加密方案,我推荐对称加密,因为非对称在一端也没什么用。我们可以选择比较好的3DES。
当我们的数据以数据库的形式存在本地的话,我们就要对它进行数据库加密了。使用Android原生的数据库有自己的加密方法,如果使用的第三方的那么就要去相应的加密方法。
为了保障数据的安全传输使用Https是必须的,当然大部分情况下我们只是验证了服务端的合法性,如果想更加安全,验证客户端也是必要的。
当我们要注册或者登陆或者修改用户信息等功能的时候加密是很有必要的。还有就是支付类的信息加密更是必要的了,当然还有其他情况只要信息比较重要那么加密是必须的。
#六.后台接口安全问题
本来这些问题是后台的问题,这里涉及网站安全等,这里不做展开。只是对本次安全检测的一些问题进行一下说明
。客户端要做的就是提示用户。
登录接口未做错误次数限制。
短信接口可能存在缺陷,攻击者可滥用此接口进行短信轰炸。
后端可添加重试次数以及IP地址等限制。