BTW：昨天的 渗透测试 的流程及渗透测试相关概念，值得回顾。另外，本文的最后面，我们把渗透测试的文章形成了一个列表，供大家参考。
APP安全测试方案
安全威胁分析
面临的主要风险
APP安全测试内容
还有最重要的：服务器和业务逻辑安全
安全测试流程
移动APP安全测试要点
新技术新业务移动APP评估思路
在这次的移动APP安全测试实例中，工作小组主要通过如下7个方向，进行移动终端APP安全评估：
运营商自主开发的自动化APP安全检测工具，通过”地、集、省”三级机构协作的方式，来完成移动终端APP安全检测与评估。APP测试思路如下：
AndroidManifest.xml文件中allowBackup属性值被设置为true。当allowBackup标志为true时，用户可通过adb backup来进行对应用数据的备份，在无root的情况下可以导出应用中存储的所有数据，造成用户数据的严重泄露。
整改建议
将参数android:allowBackup属性设置为false，不能对应用数据备份。
WebView漏洞
应用中存在WebView漏洞，没有对注册JAVA类的方法调用进行限制，导致攻击者可以利用反射机制调用未注册的其他任何JAVA类，最终导致javascript代码对设备进行任意攻击。
应用程序在登录过程中，使用http协议明文传输用户名和密码，并未对用户名和密码进行加密处理。通过监控网络数据就可以截获到用户名和用户密码数据，导致用户信息泄露，给用户带来安全风险。
整改建议
在传输敏感信息时应对敏感信息进行加密处理。
任意账号注册
使用手机号133*****887注册某个APP，获取验证码46908；
在确认提交时，拦截请求，修改注册的手机号码，即可注册任意账号，这里修改为1338*****678（任意手机号）；
分别使用133*****887和133*****678（任意手机号）登录，均可以通过验证登录，看到最终结果。
应用存在钓鱼劫持风险。应用程序没有做防钓鱼劫持措施，通过劫持应用程序的登录界面，可以获取用户的账号和密码，可能导致用户账号信息的泄露。
整改建议：
应用程序自身通过获取栈顶activity，判断系统当前运行的程序，一旦发现应用切换（可能被劫持），给予用户提示以防范钓鱼程序的欺诈。
获取栈顶activity（如下图），当涉及敏感activity（登录、交易等）切换时，判断当前是否仍留在原程序，若不是则通过Toast给予用户提示。
使用HTML5架构或android+HTML5混合开发，实现登陆、支付等关键页面，降低被劫持的风险。
移动APP典型安全漏洞
在对移动APP的渗透测试工作中个，笔者总结了几个常见的移动APP安全漏洞，包括图形验证码逻辑后门、用户敏感信息泄露、开发商被渗透，各位经常从事APP开发工作的朋友们，需要引起注意了。
图形验证码逻辑后门
案例概述
A公司是一个已经上市的信息科技公司，国内多家商业银行都是其客户。在分析A公司的移动银行产品时，发现产品的图形验证码机制存在逻辑后门可以被绕过，利用这个缺陷可以窃取大量用户账号。由于外包团队的代码复用，我们已经在至少两家商业银行的移动银行系统中复现了这个安全问题。
后果：大规模账号暴力破解攻击。
一般来说，大部分用户都习惯将移动银行密码设置为六位数字，而且查询密码和交易密码也有很大的概率设置为相同的。攻击者可以查找该地区的手机号码段范围作为登录用户名，以六位数字组成的密码字典进行暴力破解，几十万移动银行帐户信息唾手可得。
B公司也是一家上市的科技公司，其金融客户遍布全国，采用B公司移动银行方案的客户包 括至少两家全国性股份制商业银行和多家城市商业银行。在分析B公司的移动银行产品安全性时，发现没有关闭服务端的调试接口，造成大量的用户敏感信息泄露。这种问题其实也比较常见，往往是外包开发完成后上线过程的疏忽造成的，实际上更常见的例子是Android客户端通过logcat输出调试信息的问题。
调试接口会将用户转账的详细信息输出到 web 目录的 test.log 文件中。攻击者可以通过浏览器直接访问到这个 log 文件，该系统的每一笔转账交易都记录在其中，从中可以获取大量的用户账号、手机号、卡号和交易密码等信息。
开发商被渗透
案例概述
国内某漏洞平台曾经曝光过这样一个漏洞：某大型银行的移动银行ios客户端中存在一个txt文件，文件中存储了一个svn服务器的ip地址、用户名和密码，黑客解压出该文件获取信息后可以直接连上并checkout服务器上的文件。
svn 服务器上存储的内容包括该银行移动银行系统的全部项目文档、完整的 Android 和 IOS 客户端代码，甚至还存放了用于客户端签名的数字证书。
