移动App安全测试要点-InfoQ

在《运营商渗透测试与挑战》中，随着运营商新技术、新业务的发展，运营商集团层面对安全的要求有所变化，渗透测试工作将会面临内容安全、计费安全、客户信息安全、业务逻辑及 APP 等方面的挑战。

随着运营商自主开发的移动 APP 越来越多，这些 APP 可能并不会通过应用市场审核及发布，其中的安全性将面临越来越多的挑战。这个问题也引起运营商的足够重视，为此开发了自动化检测工具并开展定期的 APP 安全测试评估工作。

移动 App 面临的威胁

随着智能手机和 iPad 等移动终端设备的普及，人们逐渐习惯了使用应用客户端上网的方式，而智能终端的普及不仅推动了移动互联网的发展，也带来了移动应用的爆炸式增长。在海量的应用中，APP 可能会面临如下威胁：

木马
病毒
篡改
破解
钓鱼
二次打包
账户窃取
资源篡改
广告植入
信息劫持
…

移动 App 评估思路

在这次的移动 App 安全测试实例中，主要通过七个方面进行移动终端 App 安全评估：

能力调用
资源访问
通信安全
键盘输入
认证鉴权
敏感信息安全
反逆向

运营商自动化 App 测评思路

安全检测要点

1.Allowbackup 漏洞

AndroidManifest.xml文件中 allowBackup 属性值被设置为 true。当 allowBackup 标志为 true 时，用户可通过 adb backup 来对应用数据进行备份，在无 root 的情况下可导出应用中存储的所有数据，造成用户数据的严重泄漏。

整改建议：将参数 android:allowBackup 属性设置为 false，不能对应用数据备份。

2.WebView 漏洞

应用中存在 WebView 漏洞，没有对注册 JAVA 类的方法调用进行限制，导致攻击者可以利用反射机制调用未注册的其他任何 JAVA 类，最终导致 javascript 代码对设备进行任意攻击。

整改建议：通过在 Java 的远程方法上面声明一个@JavascriptInterface 来代替addjavascriptInterface；在使用 js2java 的 bridge 时候，需要对每个传入的参数进行验证，屏蔽攻击代码。

注意：控制相关权限或者尽可能不要使用 js2java 的 bridge

3. 关键数据明文传输

在登录过程中，应用程序使用 http 协议明文传输用户名和密码，并未对用户名和密码进行加密处理。通过监控网络数据就可以截获到用户名和用户密码数据，导致用户信息泄露，给用户带来安全风险。

整改建议：在传输敏感信息时，应对敏感信息进行加密处理。

4. 任意账号注册

用手机号133*****887注册某个 APP，获取验证码 46908。

在确认提交时，拦截请求，修改注册的手机号码，即可注册任意账号，这里修改为1338*****678（任意手机号）。

然后，分别使用133*****887和133*****678（任意手机号）登录，均可以通过验证登录，看到最终结果。

整改建议：注册过程最后的确认提交时，服务器应验证提交的账号是否是下发验证码的手机号。

5. 登录界面可被钓鱼劫持

应用存在钓鱼劫持风险。应用程序没有做防钓鱼劫持措施，通过劫持应用程序的登录界面，可以获取用户的账号和密码，导致用户账号信息泄露。

整改建议：应用程序自身通过获取栈顶 activity，判断系统当前运行的程序，一旦发现应用切换（可能被劫持），给予用户提示以防范钓鱼程序的欺诈。获取栈顶 activity（如下图），当涉及敏感 activity（登录、交易等）切换时，判断当前是否仍留在原程序，若不是则通过 Toast 给予用户提示。

使用 HTML5 架构或 android+HTML5 混合开发，实现登陆、支付等关键页面，降低被劫持的风险。

有争议的整改建议

在实施整改过程中，运营商、App 厂商以及安全厂商就如下几点可能存在争议：

关键数据明文传输

根据客户测评结果以及移动终端 APP 厂商理解，目前的数据安全问题可分为：

客户端安全（数据录入）
客户端到服务器安全（数据传输）
服务器端安全（数据存储）

而关键数据明文传输属于客户端数据录入安全。针对此部分，目前不仅是移动终端 APP，包括 Web 安全方面，对此部分要求也是不一而分，具体可以体现为：

具有现金流的交易平台：此类业务安全级别要求最高，在数据传输方面也是目前做得最好的。主要代表是：淘宝、京东、各大银行网银等。
具有较大社会影响力的平台：此类业务安全级别低于上述业务，但由于账户数据丢失以后，对其自身以及社会影响较大，所以在传输上也不会采取明文传输，如：百度、腾讯等。
数据丢失本身不会造成较大影响的平台：此类业务账户数据本身价值不大，丢失以后也不会造成影响，或者本身不会受到太大关注，一般都不会对传输数据进行加密。这样的例子比比皆是。

当然，也有厂商提出，明文传输在某些专业的漏洞检测和通报网站上，是不属于安全漏洞的。为了验证此异议，在某平台上提交了一份关于明文传输的漏洞，得到的结果请看下图：

登录界面钓鱼劫持

APP 应用存在钓鱼劫持风险。应用程序没有做防钓鱼劫持措施，通过劫持应用程序的登录界面，可以获取用户的账号和密码，可能导致用户账号信息的泄露。

这一条的检测结果，最大的争议在于按照整改建议整改后。对一般用户来说，没有任何作用。首先，我们了解一下钓鱼劫持是如何产生的。

Android 的钓鱼原理

需要理解，Android 启动一个 Activity 时，是这样设计的，给 Activity 加入一个标志位FLAG_ACTIVITY_NEW_TASK，就能使它置于栈顶并立马呈现给用户。但是这样的设计却有一个缺陷：如果这个 Activity 是用于盗号的伪装 Activity 呢？这种现象在 XcodeGhost 事件中，已经被证实是可以实现的。

在 Android 系统中，程序可以枚举当前运行的进程而不需要声明其他权限，这样的话，就可以编写一个程序，启动一个后台服务，这个服务不断地扫描当前运行的进程，当发现目标进程启动时，就启动一个伪装的 Activity。如果这个 Activity 是登录界面，那么就可以从中获取用户的账号密码，具体过程如下图：