** 安全对一些涉及到直接的金钱交易或个人隐私相关的应用的重要性是不言而喻的。Android系统由于其开源的属性，市场上针对开源代码定制的ROM参差不齐，在系统层面的安全防范和易损性都不一样，Android应用市场对app的审核相对iOS来说也比较宽泛，为很多漏洞提供了可乘之机。市场上一些主流的app虽然多少都做了一些安全防范，但由于大部分app不涉及资金安全，所以对安全的重视程度不够；而且由于安全是门系统学科，大部分app层的开发人员缺乏安全技术的积累，措施相对有限。
本文将重点分析Android APP面临的安全问题、防范措施以及一系列安全技术方案的实施。
**
面临的安全问题病毒
Android病毒就是手机木马，主要是一些恶意的应用程序。比如去年央视曝光的一款名为“银行悍匪”的手机银行木马，模仿真正的手机银行软件，通过钓鱼方式获取用户输入的手机号、身份证号、银行账号、密码等信息，并把这些信息上传到黑客指定服务器。盗取银行账号密码后，立即将用户账户里的资金转走。手机木马有的独立存在，有的则伪装成图片文件的方式附在正版App上，隐蔽性极强，部分病毒还会出现变种，并且一代比一代更强大。
这些病毒有一些通用的特征：
关键信息泄露
虽然java代码一般要做混淆，但是Android的几大组件的创建方式是依赖注入的方式，因此不能被混淆，而且目前常用的一些反编译工具比如apktool等能够毫不费劲的还原java里的明文信息，native里的库信息也可以通过objdump或IDA获取。因此一旦java或native代码里存在明文敏感信息，基本上就是毫无安全而言的。
APP重打包
即反编译后重新加入恶意的代码逻辑，从新打包一个APK文件。重打包的目的一般都是上面提到和病毒结合，对正版apk进行解包，插入恶意病毒后重新打包并发布，因此伪装性很强。截住app重打包就一定程度上防止了病毒的传播。
进程被劫持
这个几乎是目前针对性最强的一种攻击方式了，一般通过进程注入或者调试进程的方式来hook进程，改变程序运行的逻辑和顺序，获取程序运行的内存信息，也就是用户所有的行为都被监控起来，这也是盗取帐号密码最常用的一种方式。
当然 hook行为不一定完全是恶意的，比如有些安全软件会利用hook的功能做主动防御（比如 LBE和我们移动安全实验室最新的apkprotect线上加固产品）。一般来说，hook需要获取root权限或者跟被hook进程相同的权限，因此如果你的手机没有被root，而且是正版apk的话，被注入还是很困难的。 数据在传输过程中遭劫持
传输过程最常见的劫持就是中间人攻击。很多安全要求较高的应用程序要求所有的业务请求都是通过https，但是https的中间人攻击也逐渐多了起来，而且我们发现在实际使用中，证书交换和验证在一些山寨手机或者非主流ROM上面存在一些问题，让https的使用碰到阻碍。
键盘输入安全隐患
支付密码一般是通过键盘输入的，键盘输入的安全直接影响了密码的安全。键盘的安全隐患来自三个方面：
之前做过一套安全键盘的方案，就是自定义话键盘+数字布局随机化。但是随机化的键盘很不符合人性的操作习惯。所以之后的随机话也去掉了。
还需要说明下，还有一种更为安全的方式就是现在trustzone的标准已经有GlobalPlatform_Trusted_User_Inteface,也就是说在trustzone里实现安全界面的一套标准，如果安全键盘在trustzone里弹出，则黑客不管通过啥手段都无法拿到密码，是目前最为安全的方式，但是trustzone依赖于设备底层实现，如果设备不支持trustzone，或者trustzone不支持GlobalPlatform_Trusted_User_Inteface标准，我们也无能为力。*
Webview漏洞
由于现在hybrid app的盛行，Webview在app的使用也是越来越多，Android 系统Webview存在一些漏洞，造成js提权。最为著名的就是传说中js注入漏洞和webkit xss漏洞，下面的章节我们会详细介绍。
服务器未做处理，遭到渗透攻击
这个最多的就是防重放攻击和注入攻击，这个不在本次文文讨论范围内。
Android APP安全体系架构熟悉Https
从本质上讲，https就是一个双向身份验证的过程，但是由于Android设备太多太乱，Android设备证书也不统一，一般只有客户端验证服务器端证书，而服务器端在https层是不会验证客户端证书的，所以实际应用场景是一个单向身份验证的过程。
schemeRegistry.register(new Scheme(“https”, SSLSocketFactory.getSocketFactory(), 443));
这个是利用google API来对https进行校验，主要检查四个方面的内容：
如果服务器所使用的根证书是自签名的，或者签名机构不在设备的信任证书列表中，这样使用httpclient进行https连接就会失败。解决这个问题的办法有几种：
最简单的做法就是httpclient不开启证书校验，信任所有证书的方式。这种办法相对来说简单很多，但安全性就相当于http一样差，黑客可以轻易伪造证书进行中间人攻击，造成用户交易数据等敏感信息泄露。现在大部分的手机浏览器为了兼容各个证书参差不齐的网站，就是采取的这样的方式，但是也有些主流浏览器对非根的证书，只检查host和有效期，如果失败，给用户提示，还能继续浏览吗还是中断了的提示来保证用户体验的同时来提升安全性。
采用了覆盖google默认的证书检查机制（X509TrustManager）的方式，在发起https连接之前将服务器证书加到httpclient的信任证书列表中，这个相对来说比较复杂一些，很容易出错，而且每个网站的自定义证书都不一样，很难找到统一的办法对所有非根证书进行证书检查。
支付密码安全
支付密码只是一个比较有代表性的数据，它其实是代表了客户端的一些敏感数据，比如银行卡号，手机号，密码，cvv，有效期等。特别对比密码和cvv这样的强敏感数据，为了提高应用程序的性能和防止别人的破解。
我们采用了RSA和AES两套加密方式对这些数据进行加密，如下图：
首先我们会生成x位的随机秘钥，要加密的数据data用该随机秘钥去加密，最后将秘钥进行Base64编码，此时的数据才是我们要上传到服务器的敏感数据，大家都知道AES是一个对称加密算法，服务端必须知道秘钥才能解密。
期待遇上一位撑着油纸伞，结着忧愁丁香一样的姑娘;或者在春暖花开时，
