前言
开发APP时经常有问到：“APP的安全怎么保障，应用程序被PJ了怎么办？手机被人捡去了怎么办？” 特别在号称“安全第一，风控牛逼”的银行系统内，移动产品安全性仍被持有怀疑态度。那我们来总结下APP安全的方向和具体知识。
1.应用程序安全
2.应用程序内敏感数据存储安全
3.应用程序前后台数据报文传输安全
一、反编译
1.反编译代码
dex2jar：将dex文件转换成jar文件。
jd-gui：将jar文件转换成java代码 ，使用jd-gui工具打开classes-dex2jar.jar这个文件就能查看Java代码。
2.反编译资源
APK文件中资源文件都是在打包的时候被编译过了，我们直接打开的话是看不到明文的。想将APK文件中的资源反编译出来，又要用到apktool工具。
apktool：用于最大幅度地还原APK文件中的9-patch图片、布局、字符串等等一系列的资源。没有反编译资源之前，AndroidManifest.xml和activity_main.xml这样的资源文件都是非明文的，无法阅读。
3.重新打包
smali文件夹的目录结构和我们源码中src的目录结构是几乎一样的，主要的区别就是所有的java文件都变成了smali文件。smali文件其实也是真正的源代码，只不过它的语法和java完全不同，它有点类似于汇编的语法，是Android虚拟机所使用的寄存器语言。 使用smali语法，修改代码，就能重新编译自己的apk。
那么如果这是别人的程序的话，我们从哪儿能拿到它原来的签名文件呢？很显然，这是根本没有办法拿到的，因此我们只能拿自己的签名文件来对这个APK文件重新进行签名，但同时也表明我们重新打包出来的软件就是个十足的盗版软件。
二、代码混淆
1.混淆的作用
（1）令 APK 难以被逆向工程，增加反编译的成本。
（2）打包时移除无用资源，减少 APK 体积。
2.启动混淆
android {
buildTypes {
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
-
minifyEnabled设置为true来开启混淆
-
shrinkResources设置为true来开启资源的压缩。需要注意，只有在启用混淆的前提下开启资源压缩才会有效。一般在打release包时才启用混淆，因为混淆会增加额外的编译时间，所以不建议在 debug 模式下启用。
-
proguard-android.txt 表示Android系统为我们提供的默认混淆规则文件，而proguard-rules.pro则是我们想要自定义的混淆规则。
3.不能被混淆的元素
（1）枚举
枚举类内部存在 values 方法，混淆后该方法会被重新命名，并抛出NoSuchMethodException。Android系统默认的混淆规则中已经添加了对于枚举类的处理，我们无需再去做额外工作。
（2）被反射的元素
代码混淆过程中，被反射使用的元素会被重命名，然而反射依旧是按照先前的名称去寻找元素，所以会经常发生NoSuchMethodException 和 NoSuchFiledException 问题。
（3）实体类
实体类即我们常说的"数据类"，当然经常伴随着序列化与反序列化操作。很多人也应该都想到了，混淆是将原本有特定含义的"元素"转变为无意义的名称，所以，经过混淆的"洗礼"之后，序列化之后的 value 对应的 key 已然变为没有意义的字段，这肯定是我们不希望的。 反序列化的过程创建对象从根本上来说还是借助于反射，混淆之后 key 会被改变，所以也会违背我们预期的效果。
（4）四大组件
Android 中的四大组件同样不应该被混淆。原因在于： 四大组件使用前都需要在 AndroidManifest.xml文件中进行注册声明，然而混淆处理之后，四大组件的类名就会被篡改，实际使用的类与manifest中注册的类并不匹配，故而出错。其他应用程序访问组件时可能会用到类的包名加类名，如果经过混淆，可能会无法找到对应组件或者产生异常。
（5）JNI 调用的Java 方法
当 JNI 调用的 Java 方法被混淆后，方法名会变成无意义的名称，这就与 C++ 中原本的Java方法名不匹配，因而会无法找到所调用的方法。
（6）自定义控件不需要被混淆
（7）JavaScript 调用 Java 的方法不应混淆
（8）Java 的 native 方法不应该被混淆
（9）项目中引用的第三方库也不建议混淆
三、四大组件
问题1：动态注册Receiver风险
使用BroadcastReceiver组件需要动态注册或者静态注册，如果动态注册广播，即在代码中使用registerReceiver()方法注册BroadcastReceiver，只有当registerReceiver()的代码执行到了才进行注册，取消时则调用unregisterReceiver()方法。但registerReceiver()方法注册的BroadcastReceiver是全局的并且默认可导出的，如果没有限制访问权限，可以被任意外部APP访问，向其传递Intent来执行特定的功能。因此，动态注册的BroadcastReceive可能会导致拒绝服务攻击、APP数据泄漏或是越权调用等安全风险
解决方案：
1.在 AndroidManifest.xml 文件中使用静态注册 BroadcastReceiver，同时设置 exported="false"，不被外部应用调用。
2.必须动态注册 BroadcastReceiver时，使用registerReceiver(BroadcastReceiver,IntentFilter,broadcastPermission,android.os.Handle)函数注册。
3.Android8.0新特性想要支持静态广播、需要添加intent.setComponent(new ComponentName())，详情可以自行查阅
问题2：公共组件配置风险
Activity、Service、Provider、Receiver四大组件若配置为android:exported=”true”，将可以被外部应用调用，这样存在安全隐患的风险。
解决方案：
在应用的AndroidManifest.xml文件中，设置组件的android:exported=”false”或者通过设置自定义权限来限制对这些组件的访问。值得一提的是，若部分功能使用前提是配置必须使用exported为true，这种情况开发者应该根据实际情况来进行集成
问题3：数据越权备份风险
Android 2.1以上的系统可以为APP提供应用程序数据的备份和恢复功能，该功能由AndroidMainfest.xml文件中的allowBackup 属性值控制，其默认值为true。当该属性没有显式设置为false时，攻击者可通过adb backup和adb restore对APP的应用数据进行备份和恢复，从而可能获取明文存储的用户敏感信息，如用户的密码、证件号、手机号、交易密码、身份令牌、服务器通信记录等。利用此类信息攻击者可伪造用户身份，盗取用户账户资产，或者直接对服务器发起攻击。
解决方案：
将AndroidMainfest.xml文件中的allowBackup属性值设置为false来关闭应用程序的备份和恢复功能；也可以使用专业安全加固方案的本地数据保护功能，避免本地数据泄露。
四、截屏录屏
问题：截屏攻击风险
截屏攻击是指在APP运行过程中，界面被监控并且截屏或者录屏。截屏攻击主要发生在APP登录、身份认证、资金操作等界面。Android5.0中增加了一个MediaProjection接口，它提供截屏或者录屏的服务，准许APP拥有截取屏幕或者记录系统音频的能力。同时系统允许其他消息窗口覆盖在系统的录制提示上，从而在用户无感知的情况下启动录屏或者截屏工具。通过此方式，攻击者可以获取APP关键界面的截图或者录像，从而获取用户的敏感信息。
解决方案：
在Activity的oncreate()方法中调用：getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);或者getWindow().addFlags(WindowManager.LayoutParams.FLAG_SECURE);来达到防止截屏攻击的目的。
五、WebView安全漏洞
问题1：WebView明文存储密码带来的安全漏洞
WebView组件默认开启了密码保存功能，会提示用户是否保存密码，当用户选择保存在WebView中输入的用户名和密码，则会被明文保存到应用数据目录的databases/webview.db中。攻击者可能通过root的方式访问该应用的WebView数据库，从而窃取本地明文存储的用户名和密码。
解决方案：
开发者调用 WebView.getSettings().setSavePassword(false)，显示调用API设置为false，让WebView不存储密码。
问题2：WebView远程代码执行漏洞
Android API level 17以及之前的系统版本，由于程序没有正确限制使用addJavascriptInterface方法，远程攻击者可通过使用Java Reflection API利用该漏洞执行任意Java对象的方法。通过addJavascriptInterface给WebView加入一个JavaScript桥接接口，JavaScript通过调用这个接口可以直接与本地的Java接口进行交互。就有可能出现手机被安装木马程序、发送扣费短信、通信录或者短信被窃取，甚至手机被远程控制等安全问题。
解决方案：
如果一定要使用addJavascriptInterface接口，需使用以下方法：设置minSdkVersion值大于或等于17，使应用不能在4.2以下系统上运行，允许被JavaScript调用的方法必须以@JavascriptInterface进行注解声明。
问题3：未移除有风险的WebView系统隐藏接口漏洞
根据CVE披露的WebView远程代码执行漏洞信息（CVE-2012-663、CVE-2014-7224），Android系统中存在一共三个有远程代码执行漏洞的隐藏接口。分别是位于android/webkit/webview中的“searchBoxJavaBridge”接口、android/webkit/AccessibilityInjector.java中的“accessibility”接口和“accessibilityTraversal”接口。调用此三个接口的APP在开启辅助功能选项中第三方服务的Android系统上将面临远程代码执行漏洞。
解决方案：
如果应用内使用了WebView组件，那么使用 WebView.removeJavascriptInterface(String name) API时，显示的移除searchBoxJavaBridge、accessibility、accessibilityTraversal这三个接口。
六、数据存储安全
1.秘钥及敏感信息
此类配置应当妥善存放，不要在类中硬编码敏感信息，可以使用JNI将敏感信息写到Native层。
2.SharePreferences
首先不应当使用SharePreferences来存放敏感信息，sharedpreferces存储的xml文件数据可能被反编译拿到。存储一些配置信息时也要配置好访问权限，如私有的访问权限 MODE_PRIVATE（Activity.MODE_PRIVATE,//默认操作模式，代表该文件是私有数据，只能被应用本身访问，在该模式下，写入的内容会覆盖原文件的内容），避免配置信息被篡改。
3.SQLite数据库文件的安全性
解决方案：
敏感信息是否明文存储，比如账号密码之类重要信息进行加密存储，加密主要有对称加密、非对称加密、摘要算法。
（1）对称加密AES/SM4
AES主要是用在数据本身的加密，即使传输过程中被截取了，也是加密过后的数据。但AES的弊端的是，客户端加密的话，密钥肯定是储存在app中，如果app被成功PJ了，数据也就被暴露了。所以只有app本身程序的安全也解决了，app才能相对安全。
（2）非对称加密RSA/SM2
因为RSA加密有个长度限制，这就导致了RSA加密不能用于所有的数据交互。但是可以用到一些短数据，比如用户个人信息之类的，在交易中，一次订单的数据也不是很大等。
（3）摘要算法
比如MD5、SHA-1、SM3等。所谓的不可逆加密就是，只能单向加密，不能反向解密。MD5把数据加密，最后得到固定长度的16进制编码。这个加密的作用一般是匹配验证，验证某个数据是否改变。比如密码，在向服务器存储密码，一般不会存储明文密码。安卓本地存储个标志也一般不会明文存储。
（4）JNI写入Native层
七、日志数据泄露：Log控制，正式环境不打印
问题：日志数据泄露风险
调试信息函数可能输出重要的调试信息，常见的就是Log日志类其中包含的信息可能会导致用户信息泄露，泄露核心代码逻辑等，为发起攻击提供便利，例如：Activity的组件名；通信交互的日志；跟踪的变量值等
解决方案：
应用内使用统一的Log控制基类，可以灵活的控制Log的输出打印。（测试环境允许打印日志、正式环境不打印）；或者使用第三方的日志框架
八、zip包下载漏洞
问题：ZipperDown漏洞
如果大量应用会读取zip压缩包进行相关逻辑业务，常见的场景就是从服务器下载压缩包，进行资源、代码热更新。在解压zip包时，如果对文件名没有进行限制，通过在文件名加上 ../../ 前缀的方式，可以将文件解压到任意路径。如果攻击者用远程劫持或者本地替换等方式将APP将要加载的正常zip包替换为带有路径前缀的恶意zip包，而APP又未对解压文件的文件名称进行处理，则可能会出现攻击者可以对应用资源、代码进行任意篡改、替换，从而实现远程代码劫持等安全问题。
解决方案：
1.对zip包进行解压操作时，在获取文件名后，添加过滤代码对文件名中可能包含的 ../ 进行过滤判断。
2.使用通信协议加密技术，对通信过程中的数据进行加密保护，保证数据不被篡改。
3.建议客户端与服务端使用加密通道进行数据交互，并对传输数据进行完整性校验，防止zip包被拦截替换。
九、H5资源文件篡改
问题：H5文件可被篡改
应用内若存在明文存储的H5资源文件，则会泄露页面基本布局和一些重要的信息，如登录界面、支付界面等。攻击者可篡改H5资源文件，可能植入钓鱼页面或者恶意代码，导致用户账号、密码、支付密码等敏感信息泄露。更有甚者，通过H5代码暴露相关活动的业务逻辑，可能被黑产团队用来刷红包、薅羊毛等，造成经济损失。
解决方案：
可以使用第三方的专业安全加固方案，对应用中的H5文件进行加固保护。
十、so文件PJ
问题：So文件加固检测
so文件为APK中包含的动态链接库文件，Android利用NDK技术将C/C++语言实现的核心代码编译为So库文件供Java层调用。so文件被 PJ可能导致应用的核心功能代码和算法泄露。攻击者利用核心功能与算法可轻易抓取到客户端的敏感数据，并对其解密，导致用户的隐私泄露或直接财产损失。
解决方案：
对so文件进行安全加固、可以使用第三方的安全平台so加固方案。
总结
以上是APP开发中需要注意的安全问题。不要等到项目投产时再去统一检测和检查APP安全问题。项目启动时，安全的事宜就要做到心里有数了。
