移动金融应用面临的风险及应对思考
2015/7/1 11:08:38

  一、移动金融发展及信息安全背景

  随着移动互联网和智能手机的快速发展,近年来,手机端金融业务的交易量与支付额在不断地快速提升,移动金融已经成为互联网金融最具成长力的组成部分。尤其是,移动端二维码、NFC等新兴支付手段不断涌现,客户交互体验不断提升,同时在线支付、手机网上购物等移动应用快速普及,移动金融显现出了无可比拟的创新活力与市场前景,成为了银行业在互联网金融领域寻求突破的重要阵地。

  为顺应移动金融发展的大潮,各家商业银行纷纷推出了包括手机银行在内的形式丰富的各类移动金融应用,面向不同人群、不同场景,提供灵活便捷的移动金融服务。

  但是,在移动金融快速发展的同时,涉及系统和信息的安全问题也显得越来越突出,越来越重要。一方面,手机这些移动智能设备已经深入人们工作、学习、生活的方方面面,其业务应用也越来越多地涉及商业秘密和个人隐私等敏感信息;另一方面,包括移动支付在内的移动金融涉及互联网服务端和移动用户终端之间的信息互联,所以传统互联网安全的内容完全适用:服务器安全需要维护,阻止网络攻击,阻止黑客窃取数据;终端安全需要维护,要阻止病毒、木马窃取用户隐私信息,要加密敏感数据,等等。同时,移动互联网下终端设备的移动属性使得物理安全较固定设备更为突出,而目前尚未形成统一可行的防范方法。所以,移动支付、移动金融的崛起又将系统和业务安全进行了重新定义,需要我们给予更多的关注,尤其是银行,直接关系着我国金融系统的稳定和安全,在推进移动金融的同时,更要加强信息安全的防护和建设。

  二、移动金融应用可能面临的信息安全风险

  从技术的角度来观察,一个典型的商业银行移动金融应用,其部署架构可简化为下图所示:

  典型的移动金融应用部署架构示意图

  整个系统主要包含客户端、网络通信、应用服务端三大部分,相对应地,系统可能面临的安全风险主要也体现在这三个环节。

  (一)客户端安全

  1.客户端应用程序自身的风险

  由于现在智能手机尤其是android手机的生态环境较为开放,权限控制灵活,应用分发渠道众多,而android应用又是基于java语言开发,具有易反编译、易修改等特点,所以android应用自身可能面临诸多风险,包括:

  (1)被反编译。盗版者通过对应用进行反汇编、反编译获取应用核心代码,并加以利用。

  (2)被篡改、盗版等。如:动态注入外挂、木马等恶意内容;盗版者通过破解,向应用添加外挂、木马、病毒等恶意内容,窃取用户的账户密码等隐私信息。

  (3)被非法植入广告代码。如:盗版者通过替换、植入的形式,在应用中捆绑第三方广告代码,获取非法收入。

  (4)动态调试,获取或修改内存数据。用户通过调试工具,在应用运行过程中修改内存数据。

  (5)取得root权限,获取或修改数据存储文件。用户通过数据库管理工具,修改应用保存的数据库文件。

  2.基于仿冒应用的钓鱼欺骗

  通过仿冒正版应用诱骗用户安装,进而窃取用户输入的账号、密码、身份证号、交易内容等敏感信息。

  3.基于短信、网站欺诈的钓鱼欺骗

  不法分子通过伪造或者仿冒银行专用短信号码,向客户发送类似于程序升级、客户某些设置过期需要修改之类的短信,诱导客户前往钓鱼网站输入登录名、密码、卡密码、动态设备密码等信息,然后同步使用客户的账号、密码来登录应用,从而非法获利。

  4.界面劫持

  病毒或者木马程序在后台检测到客户启动金融类APP时,弹出一层透明的界面遮罩到其操作界面上层,当客户输入用户名密码时,以为是在金融机构发行的正版APP界面上输入,实际上则是被非法软件截获。

  5.“撞库”攻击

  2014年12月25日,乌云漏洞平台曝出:大量包括用户的账号、明文密码、身份证、邮箱、手机号等在内的12306用户数据在互联网上疯狂传播。由于此事件涉及到用户信息安全、账号财产安全等问题,在短时间内引起高度关注。

  据相关专家分析,此次泄露的信息极有可能是黑客利用“撞库”的方式整理后形成。所谓“撞库”,简单解释,就是黑客先攻破一些防护手段不强的小网站,获得大量的用户名和密码,然后利用用户习惯于在不同网站共用一套用户名和密码的特点,将获得的用户名和密码在别的网站(如12306)进行大规模自动化尝试。

  对于一般的android应用程序,借助类似于自动化测试平台录制脚本的技术手段,也是可以利用“撞库”方式尝试攻击的。

  6.暴力登录尝试

  暴力登录的初级版本是,利用攻击程序或者脚本,固定登录用户名,自动化尝试可能的密码组合,直到正确为止。但一般的应用都限制了登录密码连续输错的次数,当密码连续输错超过一定次数后,密码会被临时锁定。

  后来,暴力攻击演化出了一种新方式:固定一个常用密码,枚举所有可能的用户名,直到成功。这种攻击,和前述的“撞库”攻击方式很类似,本质上做法都一样。

  7.外联风险

  开放是互联网的一大特性。很多移动金融应用为了充分整合外部资源,或以APP集成、或以web接入的方式引进了不少第三方应用或者服务。当第三方应用出现安全漏洞时,对于集成它的移动金融应用及客户来说,也会带来直接风险,如信息泄露、资金转移等。

  (二)网络通信安全

  1.通信信道信息安全

  从移动终端发出请求,经过运营商网络或互联网,到达我们的防火墙,在这样的一个过程中,信息在多个不同的组织和节点中传输,如接入点、ISP的路由器、交换机、骨干网络等,如果采用普通的HTTP协议,当不怀好意的用户侵入这其中任何一个节点时,都有可能窃取、修改传输的数据。

  2.https嗅探劫持

  为保证网络通信信道安全,业界通用的做法是采用标准的https协议。但是,2013年国内某机构网络安全中心在日常终端安全审计中发现,在Android平台中使用https通讯的app绝大多数都没有安全的使用google提供的API,直接导致https通讯中的敏感信息泄漏甚至远程代码执行。

  究其原因,开发者在使用代码开发测试自己产品的https功能时,会因无法通过google API的https证书合法性而发生多种类型的https异常。为解决上述异常,开发者通常会采用了覆盖google默认的证书检查机制(X509TrustManager)的方式,为信息泄露埋下隐患。黑客可通过流量劫持,截获https握手时下发的证书,替换为伪造的假证书。随后,全部的https数据都在监控之下,可随意篡改数据包的内容。

  (三)应用服务端安全

  1.DDoS攻击

  虽然我们采用了安全的加密信道,所有的通信内容都是加密的,也采用了网络防火墙,但是攻击者利用分布式服务器,结合自动化程序或者脚本,频繁的向我们的服务端发起请求,可能会造成系统资源被大量占用,从而导致服务端响应变慢甚至瘫痪。

  2.Session重放攻击

  通过监听与截获,将用户从客户端发给服务端的请求重新发送一遍,从而试图重复被监听者之前进行过的操作,如转账、查看关键信息等。

  3.SQL注入

  当应用程序对于输入值合法性判断的不够完备,同时,服务端逻辑以用户或者外部的输入直接动态构造SQL查询的命令,将可能改变SQL查询语句本来的语义,从而导致执行任意的SQL命令,泄露或者篡改SQL数据库的敏感数据。

  4.传统互联网应用服务端存在的其它风险

  其它一些传统互联网应用服务端存在的安全风险,如目录遍历、物理路径泄露、缓冲区溢出、失效的访问控制等,在移动互联网应用中也同样需要重视。

  三、针对安全风险的应对策略思考

  对于上述列举的各类问题或攻击,我们如果采取有针对性的技术措施,是完全可以大大的降低风险甚至进行有效的防范的。

  1.客户端程序安全加固

  针对移动金融客户端(尤其是android应用)所面临的风险,如被破解、盗版、篡改、动态调试、修改本地文件等,已有许多专业的安全公司具备了对移动应用进行安全加固的技术,通用的说法就是“加壳”,通过对应用程序本身的加密保护,来大幅增加上述一系列攻击行为的难度,从而有效降低风险。建议金融机构借鉴研究相关“加壳”技术或者与专业安全机构合作,在移动APP发布前,进行有效的安全加固。

  2.钓鱼应用和钓鱼网站的防护

  针对钓鱼类的风险,在运营层面上,要通过多种渠道加强客户的宣传教育,广泛告知客户下载客户端应用的正规方式,防止客户下载到山寨版应用;提示客户谨慎进入不确信的网站,并不要将自己的个人信息(各类密码、动态码等)随意泄露,以免造成不必要的损失。在技术层面上,金融机构可以考虑和专业的第三方安全公司合作,一方面,引入应用检测机制,当用户安装非官方应用时,警告客户不要安装甚至阻止安装;另一方面,对各分发渠道、论坛、网站等进行检索、分析,尝试自动发现山寨应用、钓鱼应用的来源,并会同工信部门、公安部门采取必要措施。同时,应用层面还要加强对用户身份认证的能力,如手机号绑定、终端绑定、USB Key硬件证书等,加大钓鱼成功的难度。

  3.应用“清场”机制

  对于界面劫持之类的风险,当应用检测到自身被遮罩或者切换到后台时,建议给客户以警告提示。更进一步,应用在启动时或者进行关键性交易前,可以考虑引入“清场”机制,清除在后台运行的可疑程序。

  4.防自动化登录

  对于“撞库”或者暴力登录类攻击,其本质是利用自动化程序进行频繁尝试,所以我们的应对措施就是要加大自动化尝试的难度。如密码键盘、复杂的图形验证码、用户名与终端绑定等。

  5.https安全

  网络通信层的信息安全,基于SSL的https协议一般就能满足安全传输要求。但是,正如上面所列举到的,在android平台使用https通讯时,如果没有安全的使用google提供的API,同样会存在信息泄露的风险。所以,在产品研发环节,一定要严格按照安全标准和规范来进行开发。

  6.网络入侵检测和应用监控

  针对应用服务端可能面临的DDoS攻击,一方面我们可以在网络层尝试进行入侵检测和控制,如借助防火墙的访问控制,可以:(1)过滤接口调用错误的网络请求;(2)过滤机器人主动频繁网络请求;(3)过滤DDOS持续网络攻击;(4)过滤黑名单IP地址;(5)采用超时中断处理机制,防止无动作连接被非法劫获;等等。另一方面,应用层也可以增加监控和检测机制,当识别到某一用户名短时间内频繁登录系统,或者同一用户多笔业务操作间隔明显低于正常情况时,也可以采取适当的限制措施。

  7.对外接应用的审核、安全检测及应急切断

  为了防范外联风险,在业务和运营上,我们一定要制定严格的外部应用接入规范,增加规范审核、安全检测等机制,同时,要建立有效的应急机制,一旦接入的外部应用出现安全漏洞,要及时对入口进行临时限制或屏蔽,并同步做好客户的引导支持。

  8.其它传统风险的防护

  对于session重放、SQL注入以及其它等传统互联网应用同样面临的风险,成熟的解决方案都有很多,一方面要求我们的开发人员严格按照开发标准和安全规范来执行,如输入输出合法性检查、SQL编程规范等,另一方面要求我们在进行系统设计时,充分考虑各环节风险的应对措施,如防session重放的随机数机制、基于安全信道的一次一密加密机制等。

  四、总结

  “道高一尺,魔高一丈”,随着新技术、新手段的不断发展,各种新的风险也会不断出现,系统安全的加强是无止境的。尤其是在移动金融迅速发展、影响力越来越大的背景下,移动金融应用的整体信息安全要求也越来越高、越来越重要,我们只有从制度、技术、业务、运营、运维等多个层面、多个环节加强重视,共同努力,防微杜渐,才能保障移动互联时代的金融安全,全面守护银行安全稳健运营,为移动金融的健康发展保驾护航。

  推荐微信公众号,NFC日报:nfcdaily 移动支付网:mpaypass

本文转载目的在于知识分享,版权归原作者和原刊所有。如有侵权,请及时联系我们删除。

展开全文
相关阅读
资讯查询取消