手机银行客户端测评研究软件技术.docx

手机银行客户端测评研究软件技术.docx

《手机银行客户端测评研究软件技术.docx》由会员分享，可在线阅读，更多相关《手机银行客户端测评研究软件技术.docx（5页珍藏版）》请在冰豆网上搜索。

手机银行客户端测评研究软件技术

作者：

ZHANGJIAN

仅供个人学习，勿做商业用途

手机银行客户端测评研究-软件技术

手机银行客户端测评研究谢学兵1周亦敏1张春柳21（上海理工大学光电工程与计算机学院上海200093）2（上海计算机软件评测重点实验室上海201112）摘要手机银行客户端作为一种新型移动支付方式，它的安全问题一直受到多方面的关注。

本文通过分析目前存在的手机银行客户端安全隐患，研究常用的移动应用软件测试方法，结合手机银行客户端的特殊安全要求，提出一种适合手机银行测评的测试方法。

本文的测试方法通过对手机银行客户端进行针对性测试，发现手机银行客户端的安全问题，从而减少遭受外来攻击的风险,并通过实例来证明该测试方法的有效性和可行性，并介绍了手机银行客户端加固方法，来补充测试方法的不足之处。

关键词安全隐患，测评方法，测评实例，加固技术doi:

10.3969/j.issn.1674-7933.2015.06.003作者简介：

谢学兵，男，1989年生，学士，主要从事研究领域：

信息安全测评、等级保护测评、嵌入式应用，Email：

[emailprotected]；周亦敏，副教授，上海理工大学物理实验室主任；张春柳，工程硕士，项目经理。

0引言网上支付规模的飞速增长，淘宝网、京东商城等购物平台的出现，带给了人们不一样的购物选择，随着线上服务的与日俱增，手机支付的快捷和方便，逐渐成为人们消费付款的首选。

然而绝大多数的人们对手机的安全没有足够认识，不注重对手机安全的保护。

手机支付存在着巨大的利益，逐渐吸引着不法分子的目光，手机越来越容易遭受到外部攻击，其中手机银行作为手机支付中的一个重要组成部分更是如此。

目前对手机银行客户端的测试还没有形成一个比较完整的测试方法，在测试过程中，存在着测试盲点，更容易遭受攻击，本文研究目前普遍存在的手机银行客户端安全隐患，采用常用的应用软件测试方法，结合手机银行客户端一些自身特点，提出一种能够适用于手机银行测评的测试方法。

1手机银行客户端安全隐患分析移动银行（MobileBankingService）也可称为手机银行，是利用移动通信网络及终端办理相关银行业务的简称。

手机银行是由手机、GSM短信中心和银行系统构成。

在手机银行的操作过程中用户通过SIM卡上的菜单对银行发出指令后，SIM卡根据用户指令生成规定格式的短信并加密，然后指示手机向GSM网络发出短信，GSM短信系统收到短信后，按相应的应用或地址传给相应的银行系统，银行对短信进行预处理，再把指令转换成主机系统格式，银行主机处理用户的请求，并把结果返回给银行接口系统，接口系统将处理的结果转换成短信格式，短信中心将短信发给用户。

本文从不同系统不同版本的手机银行客户端安全威胁[1-3]中归纳出三类具有代表性的安全隐患：

1.1登录安全登录，是用户使用手机银行客户端的第一步。

在过程中，用户会输入账号、登录密码或身份证信息等重要的隐私信息，之后再交由客户端软件与服务端进行通信。

一旦用户的登录过程被攻击者监听或劫持，通信数据被截获或破解，则会导致用户账户信息被盗或银行存款被盗刷。

在登录安全中，主要存在两类安全隐患：

一类是加密机制不完整或过于简单，容易遭攻击者劫持或破解；另一类是在通信过程中不对服务端身份进行校验，从而导致登录过程很容易被“中间人”攻击劫持。

1.1.1加密机制手机银行客户端的登录加密机制通常分为两种：

一是使用HTTPS协议进行加密传输，二是使用HTTP方式进行传输，但采用自实现的加密机制来实现数据保护。

1.1.2服务端证书校验不论银行客户端使用的是何种登录加密机制，如果客户端在登录过程中不对服务端的身份（证书）进行校验，就有可能“信任”伪装身份的“冒牌服务端”，连接到假冒的银行服务端上，从而导致用户名、密码等信息被窃取。

这种假冒服务端身份的攻击也被称为“中间人攻击”。

1.2软件安全移动端程序在打包发布后，攻击者通过逆向工具将安装文件反编译为工程文件，通过逆向分析可以获取程序开发的所有源代码。

在渗透测试过程中由于程序包可以被破解，攻击者可以利用这个问题对移动应用发起白盒测试，提高漏洞探测的速度以及成功率。

对于想利用此问题发动钓鱼攻击的攻击者可以在程序中植入恶意代码，然后将二次打包的程序文件发布到互联网上的APP发布平台，一旦有用户下载并登录自己的在线银行，就会造成个人银行账号泄露或资金被盗的风险。

1.3身份认证安全目前绝大多数的手机银行客户端采用“用户名密码+短信验证码”的认证体系，即伪双因素认证体系，对于采用伪双因素认证方式的客户端来说，保证验证短信的安全性即能否保证验证短信不被劫持、窃听，成为了客户端认证机制安全性的决定因素。

然而这种基于“验证码只有手机主本人可见”的条件下才成立的安全机制非常容易被打破，窃听者可以通过短信劫持木马，使本地手机对短信进行拦截而用户本人无从知晓。

2手机银行客户端测评手机支付规模的快速增长，越来越多的银行开通了手机银行业务，研发手机银行客户端，在上线前，银行需要对研发的客户端做安全测评。

目前常用的移动应用软件检测技术主要有四类：

静置检测技术、特征码扫描技术、二进制代码逆向分析技术、动态行为检测技术[4-7]，基于手机银行客户端自身安全的特殊性，测试过程中，结合常规的检测方式，采用渗透技术对手机银行客户端进行安全测试。

2.1测评原则2.1.1风险定义在测试过程中，将所发现的安全问题，根据可能造成的影响，将问题分为高、中、低三个风险级别。

高风险：

所有可能造成当前业务的IT系统受损、资产损失、业务数据泄露的安全隐患都属于高危风险，此类问题最直接映射出的问题包括：

核心IT设施或应用系统权限被破解、核心业务宕机、重要业务数据泄露或丢失等。

中风险：

此级别的安全问题无法直接对IT系统或业务数据造成损失，涉及的安全问题在被黑客利用前都存在一定限制，造成的影响范围比较有限。

但是此类问题有助于提高黑客入侵的成功率，因此也存在一定风险。

最直接映射出的问题包括：

错误信息泄露、资源非法访问及获取、应用系统漏洞等。

低风险：

对于影响面及严重级别比较微弱的安全问题都属于低风险漏洞，这些问题无法造成直观影响，范围主要涉及：

应用信息泄露、程序版本泄露、业务模块及业务系统逻辑设计不合理等。

2.1.2测试依据目前，对于手机银行客户端的测评没有制定统一标准，本文设计的手机银行客户测评方法是严格按照OWASP（OpenWebApplicationSecurityProject）组织中列举的安全漏洞类型为依据，对每种漏洞类型可能衍生的安全问题进行详细检测。

测试分类见表1。

2.2测试内容2.2.1数据流安全对客户端和服务器之间交互的数据的保密性进行检测，分析数据的加密机制是否存在破解的可能性。

测试工作包括以下内容：

分析当前数据传输的模式，尝试从通讯数据中获取API接口函数、数据传输协议、服务端构架等；检测数据加密过程中使用的加密协议，判断SSL（HTTPS）加密协议的版本，证书有效性等信息；尝试对转码后的数据进行逆向，获取明文信息。

2.2.2APP代码安全根据APP所依赖的平台和开发环境，逆向破解APP程序包，尝试获取程序开发的源代码，并根据源代码的安全性进行检测。

测试工作包括以下内容：

逆向破解APP程序包，尝试获取编译前的源代码；对当前程序包的加密技术进行测试，分析当前加密机制以及被反编译的可能性；分析程序运行的权限和所需的功能点，判断是否存在越权访问或过度访问的问题。

2.2.3配置文件安全性APP在安装完成后将自动生成多个配置文件，其中可能包含敏感的用户数据或者配置参数，尝试对相关的配置文件以及系统调用的函数进行测试，分析当前配置信息的存储模式以及对安全性、文件完整性进行检测。

测试工作包括以下内容：

分析用户登录的敏感数据是否加密保存；分析系统在调用配置文件时的完整性检测机制；分析配置信息加密的强度以及完全级别。

2.2.4程序逻辑在APP安装完成后，通过沙盒技术对程序处理的每个环节进行监控，并从客户端和服务端的交互信息中分析由于程序逻辑流程设计不严谨而存在的安全漏洞。

测试工作包括以下内容：

测试程序执行流程越权操作问题；检测程序在接收的信息中是否存在非自身用户的数据，并尝试破解；检测程序在用户登录及服务器交互过程中的数据重放问题。

2.2.5移动设备功能调用在部署完测试系统后，对当前APP调用的手机的特殊功能接口进行枚举，记录和测试当前APP不应植入的异常功能。

涉及的功能包括：

短信记录、通讯录、文件及数据、设备特权等。

测试工作包括以下内容：

统计程序运行时调用的外部接口；分析当前APP中存在的可疑动作，并进行技术跟踪；分析APP向服务端提交的数据内容，判断是否存在违规提交。

2.3测试流程在测试阶段的具体流程和步骤如图1。

3测评实例采用本文设计的手机银行客户端测评方法，对某银行的手机客户端进行了测评。

3.1测试环境3.1.1系统构架待测手机的系统框架如表2。

3.1.2业务构架结合本次渗透过程中对业务系统的了解，当前测试的应用平台由多个业务模块构成，这些模块是渗透测试的主要对象，由于本次测试的系统用途特殊，所以将业务模块和OWASPTOP10相融合并结合移动应用独有的特点，提高渗透的效果。

汇总后的分类见表3。

3.1.3程序逻辑待测手机银行客户端的程序运行逻辑如图2。

3.1.4手机接口待测手机接口状态如表4。

3.2安全问题在测试过程中，在脚本安全、程序逻辑和代码安全性方面发现安全隐患，主要包括以下内容：

3.2.1应用程序错误信息泄漏风险等级：

中风险问题描述：

测试过程中，操作人员截断移动终端发送的数据，对数据进行篡改，并提交，从服务端返回的错误信息中了解当前的拦截机制主要对输入内容的长度做了限制，其最大不能超过16个字符。

安全隐患：

数据异常时返回的具有标识的错误信息，通过分析错误内容，可以掌握服务端的安全机制，从而绕过机制，提高入侵成功率。

3.2.2越权访问账户余额风险等级：

中风险问题描述：

在测试过程中，操作人员用所属账户在手机客户端上登录后，不仅可以查询自己账户的余额，还可以通过修改银行卡号，查询其他账户的银行余额。

安全隐患：

服务端程序在查询账户余额是没有对账户及银行卡号的所有权进行验证，攻击者可以通过篡改银行卡号查询其他人的账户余额，容易造成大量用户存款数据泄漏的风险，影响银行声誉。

3.2.3数据完整性校验缺失风险等级：

中风险问题描述：

在测试过程中，操作人员通过技术手段绕过SSL算法，获取了服务端返回的明文数据，并且可以对返回的数据进行修改，而手机客户端显示修改后的数据。

安全隐患：

手机客户端的数据均来自服务端，当前应用架构中使用SSL加密算法来确保链路的安全性，但缺少对服务端返回数据的完整性校验，容易被攻击者使用，产生钓鱼或金融诈骗风险。

3.2.4程序逆向分析风险等级：

高风险问题描述：

在测试过程中，操作人员使用逆向工具将客户端安装软件反编译为工程文件，并成功分析获取了程序开发的所有源代码。

如图3、图4、图5所示。

3.3测试总结本次手机银行客户端测评中发现的4个安全问题，其中第四个高风险安全问题为本文总结的三个安全隐患中的软件安全，由于操作环境为产品上线前的测试环境，所以没有发现用户登录和身份认证的安全问题。

4手机银行客户端安全加固技术对于手机银行客户端主要的三种安全隐患，可以通过技术手段进行安全加固，从而规避风险。

4.1完善登录加密机制对于登录安全，主要的防御点是如何防御中间人攻击，在传输的过程中，建议采用体系比较完整的Https机制，若是本来采用的是Http+自实现加密机制的银行客户端，也尽量完善安全加密机制。

采用Https加密机制，除了能对登录过程中的数据进行加密，以保证传输数据的安全性和完整性之外，还支持X.509数字证书认证—基于这种数字证书认证机制，可以确认通信双方身份[8-10]。

4.2防二次打包4.2.1对APP进行签名校验每一个应用程序都会有一个数字签名，该签名代表了应用程序的发布者。

不同发布者的数字签名也是不同的，而且数字签名通常是无法伪造的。

因此，通过校验数字签名，就可以知道一个应用程序是否为正版软件，是否曾经被篡改过。

4.2.2对APP进行加固处理应用加固是先将正版应用进行反汇编，之后对程序的汇编代码进行加密和混淆处理，之后再重新编译打包生成应用，同时由正版作者对经过加固处理的应用进行重新签名。

经过这种加固处理的应用程序，虽然理论上说仍然可以进行反汇编，但由于程序事先经过了加密处理，因此反汇编之后的代码的可读性大大降低，相应的，盗版作者对程序进行逆向分析难度也就大大增加，使得盗版作者通常很难在原有代码中混入恶意代码，从而可以有效的阻止应用程序被篡改和二次打包。

4.3伪双因素认证解决移动支付过程中的伪双因素认证的问题有三种基本的思路，一个是将伪双因素认证改造成真正的双因素认证；一个是通过权限管理保证手机银行客户端能够先于木马病毒读取短信；再有一个就是通过加密保护的方式使得木马病毒无法获取验证短信的明文。

在解决伪双因素认证问题时，主要以第三个方案为主。

在实施过程中，由银行对发送到用户手机上的短信进行加密，之后需要通过手机银行客户端中的支付安全模块对短信信息进行解密还原短信内容。

由于手机收到的验证短信为密文方式，木马程序无法直接获取到有效信息，而且即便是恶意程序对加密验证码进行暴力解密，所需的时间也超过了验证短信的实际有效期。

这个方案从根本上解决了系统短信验证码容易泄露的问题。

5结束语本文提出的手机银行客户端测评方法，对可能存在安全隐患的各个环节进行测试，有目的性的测试客户端中存在的几大安全漏洞，大大缩短了测试周期，在测试的过程中，操作人员能够快速的发现问题并及时反馈给银行，银行的安全部门能够尽快的做出调整和修改，不会耽误预期的客户端上线时间，大大提高了测试实施的效率。

但本文提出的测试方法是基于产品上线前的测试环境，缺少对上线后的客户端全面监控和测试的环节，依旧可能存在安全隐患，需要银行通过技术手段对客户端进行安全加固。

本文测试方法仍需要不断的改进，提高测试的深度和广度，尽可能全面的发现存在的安全隐患。

参考文献梁宏,解万永,秦博.手机安全现状及发展趋势[C].信息与网络安全.第28次全国计算机安全学术交流会,贵州贵阳,2013-10.徐雷,卓武扬,李雪玫.基于网络的移动支付安全风险评估系统涉及[J].西华大学学报：

自然科学版,2014.33（6）:

5-10.李宏达,李林森.手机银行风险评价体系研究[J].计算机应用与软件,2014.31（12）:

303-306.张焕,武建亮,唐俊杰等.NeighborWatcher：

基于程序家族关系的附加恶意手机应用检测方法研究[J].电子学报,2014.42（8）:

1642-1646.杨卫军,秦海全,王鹏.Android移动应用软件检测平台[C].信息与网络安全.第27次全国计算机安全学术交流会,四川九寨沟,2012-08.王丽.移动应用软件测试探索[J].计算机系统应用：

专论?

综述,2013.22

（1）:

1-4.李向东,夏冰,郑秋生.Android应用软件安全测评方法研究[J].信息安全与通信保密,2014.133（3）:

133-135.张璇,林逸风,白川等.基于贝叶斯网络的移动支付风险评估模型[J].计算机工程与应用,2014.50（5）:

60-64.肖茵茵,苏开乐.电子商务支付协议认证性的SVO逻辑验证[J].计算机工程与应用,2014.50（8）:

6-10.腾震方.基于多属性的移动终端安全接入网络认证协议[J].计算机应用与软件,2013.30（8）:

43-46.

版权申明

本文部分内容，包括文字、图片、以及设计等在网上搜集整理。

版权为张俭个人所有

Thisarticleincludessomeparts,includingtext,pictures,anddesign.CopyrightisZhangJian'spersonalownership.

用户可将本文的内容或服务用于个人学习、研究或欣赏，以及其他非商业性或非盈利性用途，但同时应遵守著作权法及其他相关法律的规定，不得侵犯本网站及相关权利人的合法权利。

除此以外，将本文任何内容或服务用于其他用途时，须征得本人及相关权利人的书面许可，并支付报酬。

Usersmayusethecontentsorservicesofthisarticleforpersonalstudy,researchorappreciation,andothernon-commercialornon-profitpurposes,butatthesametime,theyshallabidebytheprovisionsofcopyrightlawandotherrelevantlaws,andshallnotinfringeuponthelegitimaterightsofthiswebsiteanditsrelevantobligees.Inaddition,whenanycontentorserviceofthisarticleisusedforotherpurposes,writtenpermissionandremunerationshallbeobtainedfromthepersonconcernedandtherelevantobligee.

转载或引用本文内容必须是以新闻性或资料性公共免费信息为使用目的的合理、善意引用，不得对本文内容原意进行曲解、修改，并自负版权等法律责任。

Reproductionorquotationofthecontentofthisarticlemustbereasonableandgood-faithcitationfortheuseofnewsorinformativepublicfreeinformation.Itshallnotmisinterpretormodifytheoriginalintentionofthecontentofthisarticle,andshallbearlegalliabilitysuchascopyright.