移动 App 安全测试要点

发布于:2020 年 7 月 1 日 11:49

移动App安全测试要点

移动App安全测试要点

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

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

移动 App 面临的威胁

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

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

移动 App 评估思路

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

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

运营商自动化 App 测评思路

移动App安全测试要点

安全检测要点

1.Allowbackup 漏洞

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

移动App安全测试要点

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

2.WebView 漏洞

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

移动App安全测试要点

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

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

3. 关键数据明文传输

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

移动App安全测试要点

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

4. 任意账号注册

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

移动App安全测试要点

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

移动App安全测试要点

移动App安全测试要点

然后,分别使用133*****887133*****678(任意手机号)登录,均可以通过验证登录,看到最终结果。

移动App安全测试要点

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

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

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

移动App安全测试要点

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

移动App安全测试要点

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

有争议的整改建议

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

关键数据明文传输

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

  • 客户端安全(数据录入)
  • 客户端到服务器安全(数据传输)
  • 服务器端安全(数据存储)

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

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

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

移动App安全测试要点

登录界面钓鱼劫持

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

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

Android 的钓鱼原理

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

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

移动App安全测试要点

检测原理描述清楚后,就需要给出让软件厂商能够明白的整改建议以及漏洞情景重现。

Android 的钓鱼情景演示

以小米手机为例:

1. 当打开 3 个 APP 时,最后一个打开的 APP”语音助手”,切换至手机桌面,长按 HOME 键查看进程,”语音助手”会显示在进程的第一个。

移动App安全测试要点

2. 点击”微信”后,切换至”微信”,再查看进程,可以看到,进程中由于”微信”已切换至当前窗口,故进程中不存在。

移动App安全测试要点

3. 从第 1 步看到,当切换至手机桌面时,无论是语音助手、手机令牌、还是微信,都是默认后台运行,而且切换出来以后无任何提示。这样,当恶意 activity 收到微信登录界面或者其他敏感界面的时候,就会抢先推送至客户,从而让客户轻易的输入帐号,并获取客户的信息,但此时微信不会做任何提示。

4. 再来观看一下某行手机 APP,当切换至手机桌面时,会对客户做出提示:

移动App安全测试要点

假设一下页面是恶意推送的 activity,那么在恶意推送的 APP 页面,应该会显示出此类提示,告知客户,此页面并非正常 App 的页面。

用户打开正常页面 VS 用户打开了恶意页面

移动App安全测试要点

本文转载自绿盟科技,原文链接

阅读数:454 发布于:2020 年 7 月 1 日 11:49

评论

发布
暂无评论