任何一款app，无论是开发过程中，或者应用上架等操作中，最先需要注意的就是我们自己应用的安全性。
Android App安全策略
技术手段
代码混淆
APK文件的安全性是非常令人堪忧的。APK运行环境依赖的文件/文件夹 res、DEX、主配文件Lib 只有简单的加密或者甚至没有任何加密。诸如apktool这类工具可轻易将其破解，再配合其他例如dex2jar、jd-gui等工具基本可以做到：源码暴露、资源文件暴露、主配文件篡改、核心SO库暴露、暴力破解恶意利用等。因此需要对安卓代码进行代码混淆。Android中使用SDK中自带的Proguard工具，添加相应配置即可。
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
使用ProGuard混淆的应用，通过apktool还是可以看到Manifest和res资源，使用dex2jar也可以看到混淆后的源码，虽然大部分代码已经混淆了。还是可以看个大概，而且通过smail的修改，重新进行逆向apk。
另一种混淆方式：DexGuard，收费，ProGuard加强版。
签名校验
Android黑产里面，有一个叫做二次打包，也称为重打包。即通过反编译正版应用后，可以获得smali源码，往其中注入代码或者修改相应业务逻辑后，再利用新的签名进行重新打包，并发布到应用市场去，很多无良开发者就是通过这种方式去破解一些付费应用或者往其中注入广告代码来获利。简单梳理一下重打包的基本流程：
- 对正版应用用apktool类逆向工具进行解包；
- 在某处地方注入smali代码；
- 利用IDE生成签名文件，再通过jarsigner进行签名；
- 上传应用市场；
为了与二次打包做对抗，可以在应用内的关键功能入口增加校验签名的检测，如果发现应用签名非正版，则强制关闭应用或者限制用户使用。加签名校验代码时，可以考虑：
- 在JNI层中加校验代码，相比在Java层的代码，JNI层的逆向难度更大；
- 如果要在Java层加校验代码，不要在一个地方暴露一段长串字符串，对于逆向工程师是来说，这是非常明显的提示。可以考虑将字符串打散存放在各处，这样会增加破解分析的难度；
应用加固
加固的原理是通过加密原应用的安装包中的dex文件，其主要操作方式大致如下：
- 准备要进行加壳的原应用安装包（以下简称原apk）、用于做壳的安装包（以下简称壳apk）；
- 对原Apk进行拆解获取各个部分，并将dex文件进行算法加密（以下简称加密原dex）；
- 将加密原dex和壳Apk中的dex进行组合，合并成为新的dex文件；
- 利用特制的打包工具合并生成加密后的apk；
详细步骤：
步骤一：将加固壳中的aar中的jar利用dx工具转成dex文件
步骤二：将需要加固的APK解压，并将所有dex文件打包成一个zip包，方便后续进行加密处理
步骤三：对步骤二的zip包进行加密，并与壳dex合成新dex文件
步骤四：修改AndroidManifest（替换Application的android:name属性和新增<meta-data>）
步骤五：将步骤三生成的新dex文件替换apk中的所有dex文件
步骤六：APK对齐处理
步骤七：对生成的APK进行签名
反调试
如果你不小心在AndroidManifest.xml配置文件中设置了application属性为debuggable=“true”，则应用可以被任意调试，这就给了攻击者极大地方便；任何apk只要反编译后拿到smali代码工程，使用smalidea调试神器，你会发现你分分钟就可以在AS中调试它。（具体操作自行搜索，操作不难）如果你觉得把核心代码放进JNI层就安全了，那么请尝试一下IDA，看看它如何让你继续调试。可以被调试意味着：获取和篡改用户敏感信息，甚至分析并且修改代码实现的业务逻辑，例如窃取用户密码，绕过验证码防护等等。
如何处理？
- 因为一个进程同时最多只能被一个进程所调试，那么我们就给自己附加进程，假装自己在调试自己，占住调试位置，用该方法来拒绝别的进程的调试请求。
- 轮训检查自身status中的TracerPid字段值，如果发现TracerPid的值不等于0则代表有进程在调试，就要杀死自己。
- 签名校验是不可或缺的一个选择，本地校验（前端）和服务器端校验双管齐下。
- 借助系统API判断应用调试状态和调试属性，这是最基础最基本的防护。
- 轮训检查Android_server调试端口信息和进程信息， 防护IDA动态调试的一种有效方式。
组件安全
四大组件安全防护就是访问权限的控制。
-
最小化组件暴露 android:exported 属性设置
-
声明访问权限 android:permission
-
组件传输数据验证（主要是跨应用组件之间数据传入传出验证，防止恶意数据注入）
-
组件私有共有设置
activity 私有activity：只能有APP内部使用的activity，最安全的activity。 公共activity：任意APP都能启动此类activity。 伙伴activity：合作伙伴APP才能启动的activity，授权。 内部activity：只有内部APP才能启动，全家桶。 Broadcast Receiver 私有广播接收器：此类广播只能被APP内部所接受，所以是最安全的广播。 公共广播接收器：此类广播没有指定具体的接收者，能被任意的APP接收。 内部广播接收器：广播只能被一些特定的APP所接收。
网络安全
使用Https和ssl证书校验
WebView组件漏洞
-
Webview明文存储密码风险
Android的Webview组件中默认打开了提示用户是否保存密码的功能，如果用户选择保存，用户名和密码将被明文存储到该应用目录databases/webview.db中。而本地明文存储的用户名和密码，不仅会被该应用随意浏览，其他恶意程序也可能通过提权或者root的方式访问该应用的webview数据库，从而窃取用户登录过的用户名信息以及密码。 -
Webview远程代码执行漏洞
Webview是Android用于浏览网页的组件，其包含的接口函数addJavascriptInterface可以将Java类或方法导出以供JavaScript调用，实现网页JS与本地JAVA的交互。由于系统没有限制已注册JAVA类的方法调用，因此未注册的其它任何JAVA类也可以被反射机制调用，这样可能导致被篡改的URL中存在的恶意代码被执行，用户手机被安装木马程序，发送扣费短信，通信录或者短信被窃取，甚至手机被远程控制。 WebView远程代码执行相关的漏洞主要有CVE-2012-6336、CVE-2014-1939、CVE-2014-7224，这些漏洞中最核心的漏洞是CVE-2012-6336，另外两个CVE只是发现了几个默认存在的接口，下面就具体说明这些漏洞的情况。 CVE-2012-6336 Android <= 4.1.2 受影响 CVE-2014-1939 Android <= 4.3.1 受影响 CVE-2014-7224 Android <= 4.4.0 受影响 可以发现其实都是些低版本系统漏洞，目前已经发展到Android 10了，理论上说不存在WebView漏洞，属于老漏洞。修复方法就是升级最新系统版本。 -
Webview绕过证书校验漏洞
客户端的Webview组件访问使用HTTPS协议加密的url时，如果服务器证书校验错误，客户端应该拒绝继续加载页面。但如果重载WebView的onReceivedSslError()函数并在其中执行handler.proceed()，客户端可以绕过证书校验错误继续访问此非法URL。这样将会导致“中间人攻击”，攻击者冒充服务器与银行客户端进行交互，同时冒充银行客户端与银行服务器进行交互，在充当中间人转发信息的时候，窃取手机号，账号，密码等敏感信息。 -
未移除有风险的Webview系统隐藏接口
android webview组件包含3个隐藏的系统接口：searchBoxJavaBridge, accessibilityTraversal以及accessibility，恶意程序可以利用它们实现远程代码执行。需通过显示调用removeJavascriptInterface移除这三个系统隐藏接口。 -
WebView忽略SSL证书错误
WebView调用onReceivedSslError方法时，直接执行handler.proceed()来忽略该证书错误。忽略SSL证书错误可能引起中间人攻击。
数据存储
- 隐藏数据存储位置
- 存储内容不要使用明文
- 代码中禁止硬编码重要信息内容
- 存储到手机内部存储上
- 慎重使用allowBackup属性，设置是否支持备份，默认值为true，如无必要，将值设置为false，避免应用内数据通过备份造成的泄露问题
业务安全
权限漏洞
- 全局文件可读写
APP在创建内部存储文件时，将文件设置了全局的可读权限。攻击者恶意读取文件内容，获取敏感信息，或恶意写文件，破坏完整性。
- 敏感权限调用
在Manifest文件中调用一些敏感的用户权限，敏感行为包括发送、拦截短信，读取、修改通讯录、通话记录，拨打电话，发送地理位置，使用摄像头，访问浏览器历史记录等。函数调用这些敏感行为，可能导致用户隐私数据泄露，钓鱼扣费等风险。
- 冗余权限
如果调用了非必须的权限，就会出现冗余权限，冗余权限可导致串谋攻击，串权限攻击的核心思想是程序A有某个特定的执行权限，程序B没有这个权限。但是B可以利用A的权限来执行需要A权限才能完成的功能。
业务漏洞
业务漏洞需要依靠机器和人共同检测，需要根据应用功能作用的不同来进行判断。机器可以检测一些通用的业务漏洞，例如广告、非授权下载、扣费短信等业务，而人工则判断应用在面向不同业务逻辑时产生的漏洞，例如登录验证不完善、不可信的敏感数据交付等。
总结
应用安全的攻防就是一个相爱相杀又相辅相成的过程，对于客户端能做到的安全防范也是有限的，更多的还是应该结合后台业务分析来实现相应的对抗机制。对于应用安全，做好现在能做的，多研究，多测试，提升安全性，保障自身利益。
429
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
