App 的安全过检与众所熟知的安全检测是两个完全不同的概念。首先 App 行业本身对 App 安全过检有一定的要求与规范,其次2017年6月1日正式实施的《中国网络安全法》中就曾要求 App 在渠道上线时进行实名认证,同时还要完成相应的安全检测。App 这一上线过程就称为安全过检或者叫做安全候审。
App 安全过检过程中遇到哪些问题
App 在具体过检时所参考的一个细则就是《移动应用安全检测基本要求》,这个要求总共分为四大类,其中包括应用层、网络层、数据层以及服务器端。而安卓 App 本身的一些安全点,总共分为十个,分别是程序代码安全、程序代码防护、密码与安全策略、权限与界面安全、动态调试检测、SO 注入检测、内存数据保护、隐私与存储安全、日志泄漏检测、通信数据安全等。
第一块与用户信息收集要求相关。APP 上架时对用户信息收集是有一定要求的,收集用户信息就明确相关的法律声明以及相关隐私政策。假如 App 没有获取用户隐私数据,但是使用了三方平台去收集,这个也要声明清楚 App 使用了哪个三方平台去收集用户数据,收集用户数据的目的等。
上图就是我们常见的一个 APP 展示页面,虽然大部分用户没有仔细阅读过以上信息,但是法律声明及隐私政策的展示是收集用户信息的硬性要求。
第二块与调用系统权限检测相关。调用系统权限需要遵循权限最小原则,同时 App 申请的权限要遵守用户的同意。
第三块是源代码的安全性,上架 APP 要给用户提供正常服务,而且不存在恶意特征行为。
App 开发者要具备基本的安全开发意识,要时刻关注 App 有没有打错包、有没有采用代码混淆技术,有没有基本的防反编译能力以及能不能在某一种程度上防篡改。
第一个混淆是指客户端是否采用了代码混淆技术;
第二个防反编译是指能够阻止三方逆向工具进行逆向反编译或者通过加固特征进行反编译;
第三个防篡改是指 App 在运行时完整性校验防篡改机制,防二次打包,修改后重新打包运行闪退即可通过。
密码与安全策略需要用户输入账号密码登录的 APP,尤其是金融类 App,在输入账号密码时需要防止三方程序捕获或截获或者是截屏,这就需要 APP 有一定的键盘保护。防键盘记录 SDK,就是当用户输入账号密码时,通过 SDK 来展示键盘供用户输入,这个 SDK 必须要求每次启动时所显示的字符序列是不一样的,这样才会被认为是通过的,是合格的。
程序数据备份需要查看 AndroidManifest.xml 中是否设置 allowBackup 标志(默认为 true)或将 allowBackup 设置为 true。如果为 true 时应用程序数据可以备份和恢复。
界面劫持是在账号密码输入的时候,除了键盘输入的字符会被截获之外,恶意程序也可能会提供一个假的界面,覆盖账号输入的页面上去,伪造一个登录页面,普通用户无法甄别登录页面的真伪,所以很可能会被钓鱼。这样的程序有一个要求,当对它进行测试的时候也会提供一个假的界面,这时 App 要弹出相关风险提示。
还有一个是截屏录屏,有些恶意程序不去拦截字符输入,因为密码输入的一瞬间字符是出现的,当输入下一个密码字符时上一个字符才会变成星号,有些恶意程序也会用到这种截屏录屏的技术。
值得一提的是,目前还没有什么专门针对Activity 劫持的防护方法,因为这种攻击是用户层面上的,目前还无法从代码层面上根除。
但是我们可以适当的在 App 中给用户一些警示信息,提示登录或关键界面已被覆盖,具体解决方案如下:
在 App 的 Activity 界面(也就是 MainActivity)中重写onKeyDown方法和onPause方法,当其被覆盖时,就能够弹出警示信息。判断程序进入后台是不是由用户自己触发的(触摸返回键或 HOME 键),如果是用户自己触发的则无需弹出警示,否则弹出警示信息。
防动态调试基本上是通过ptrace 方式进行判断,当应用被检测机构打回时,机构会给相关修复建议,修复建议里面会提到一些解决方案。
如果进程被附加处于调试状态,则/etc/\$(procID)/status 中进行 procid 的判断,如果进程 id 不为零则直接杀死本进程退出。如果进程被附加处于调试状态,则/etc/self/status 中对 TracerPid 后面的进程 ID 进行判断,如果进程 id 不为零则直接杀死本进程退出,创建子进程,子进程对其进行 ptrace,但不对子进程 ptrace,互相检查 ptrace 状态;同时还要互相检查进程是否被挂起。
APK 一旦被调试,APP 异常退出,阻断调试
当然也可以用三方的加固成品来进行实现,有些加固可能做的动态是比较完善的话也能够实现这一点。
通过对 App 进行加固,采用加固方案加固 App,防止 App 被动态调试。
SO 注入,在 App 例案里面破解手法是比较多的,无论是从linker 服务还是 dlopen 服务,SO 注入是比较实用的技能。SO 搭配上 so 库技术,可以很方便分析应用程序的一些逻辑以及 App 所要达到的一些效果。
SO 注入的防范方法主要包括以下三点:
1、对 dlopen 函数进行的判断,修改 linker 中的 dlopen 函数,防止第三方 so 加载。
2、定时检测应用加载的第三方 so 库,如果发现是被注入的 so,卸载加载的 so。
3、对被测系统进行加固,防止被测系统被动态注入第三方 so。
防 dump
dump 实际就是内存数据的读,防 dump 就是防内存被第三方程序读,可以利用类似如下命令 dump 进程内存:dd
if=/proc/3039/mem of=/data/local/tmp/dump_mem.zip skip=1979047936 ibs=1
count=1490944。监控/proc/pid/mem、/proc/tid/mem 等文件的读写操作,当这些文件被第三方程序访问时,触发设置的回调函数,并做进一步处理。
防内存修改
内存数据的修改就是内存数据的写,原理同防 dump。配合防注入、防调试等方法,最终实现防内存修改。
本地数据存储是否泄露信息检测:xml、db 文件是否明文存储;日志信息是否安全检测;
1.不要将密码等敏感信息存储在 Shared
Preferences 等内部存储中,应将敏感信息进行加密后存储。
2.避使用 MODE_WORLD_WRITEABLE 和 MODE_WORLD_READABLE 模式创建进程间通信的文件,此处即为 Shared
Preferences。
敏感数据是否加密传输检测:网络抓包 敏感数据是否加密;
对加密信道的安全性检测(包含中间人攻击检测等)HTTPS 通信协议;
建议:被测系统客户端在与服务器端通信应使用 SSL 等协议加密传输敏感信息。
自定义实现的 X509TrustManager 子类中,未对服务器端证书做验证,默认接受任意服务端证书,会存在安全风险。
被测系统忽略服务器端证书校验错误或信任任意证书,容易导致中间人攻击,可能造成用户敏感信息泄露。
在客户端对服务器端证书校验的 checkServerTrusted 方法中对证书进行校验。
WebView 漏洞:客户端 App 是否使用 webview
组件的接口函数 addJavascriptInterface,是否存在远程代码执行漏洞。
组件引起漏洞检测
鉴权机制缺陷检测
SQL 注入漏洞检测
跨站脚本攻击(xss)漏洞检测
阿里云 oss 凭证泄露漏洞检测
Struts2 漏洞检测