移动校园App潜在安全风险分析及对策研究

2020-05-29任凤君郑礼河

闽江学院学报 2020年2期

任凤君，黄磊，郑礼河

(福建医科大学信息中心，福建福州 350122)

0 引言

随着移动网络和智能设备的高速发展，高校师生获取服务的途径逐渐向智能手机、平板电脑等移动终端转移。中国互联网络信息中心在2019年8月发布的第44次《中国互联网络发展状况统计报告》中显示，截至2019年6月，我国网民规模达8.54亿，手机网民8.47亿，手机网民占比达99.1%[1]。传统PC端系统已经不能满足师生随时随地享受访问服务的需求，移动互联改变了互联网传统的应用形态，App成为新的主导形态，一个新的应用服务体系和生态环境由此而生。

如何更好地为师生提供优质服务，适应“移动优先”的发展需求，是现在智慧校园建设需要考虑的重要问题之一。然而很多高校现阶段搭建移动校园App服务的基础环境相对较弱，各类部门应用和第三方应用水平参差不齐，无法满足师生对移动端应用便捷访问的需求，同时参差不齐的应用开发水平和源代码安全，也给学校信息安全带来了新的挑战。师生在享受移动网络带来便利的同时，也面临着前所未有的安全风险。诸多不安全因素威胁着师生的工作和生活。如恶意扣费、资费消耗、信息窃取、诱骗欺诈等恶意行为的移动互联网恶意程序严重损害师生的利益，甚至危害社会稳定和国家安全[2]。高校急需构建一个开放、安全、可控的移动服务运行环境，为师生提供安全稳定、可信、权威的校内外服务。

1 移动校园App架构

师生对信息化服务的需求日益增长，不仅要求网站移动化，各类服务也要移动化, 需要为业务部门的移动应用提供支撑平台，统一信息和服务的获取途径，提高移动应用的质量，因此统一校园移动App的建设势在必行。借鉴利用网站群提供移动校园App信息服务的经验[3]，移动校园App采用了多层架构：学校支撑平台层、基础能力层、平台能力层、开放能力层、服务终端层，以及贯穿全部的安全保障层和数据标准体系层(图1)。1)学校支撑平台层包括学校原有的管理平台技术体系，即学校原有的人事、学工、教务等系统技术体系；2) 基础能力层包括地图、统一消息中心、支付、统一任务中心等；3) 平台能力层包括协作沟通、媒体内容、应用服务等，由通讯录、及时通讯、资讯信息、校园号、校园卡、课表等功能组成；4) 开放能力层为校内原有应用接入，校外应用接入，各类资讯整合，跨校应用共享提供了可能；5) 服务终端层包括移动客户端，以及微信、微信代理层等；6)安全保障层包括了各类安全设备，安全制度，安全服务等；7)数据标准体系层包括指导数据标准的规范性文件等。

图1 移动校园App架构Fig.1 Mobile campus App architecture

2 移动校园App潜在安全风险

根据移动校园App的构架及分析各应用的接入情况，可以从3个不同方面对潜在风险进行划分，主要分为客户端安全风险、通信过程安全风险和服务端安全风险[4]。

2.1 客户端安全风险

图2 客户端应用的风险Fig.2 Client application risk

客户端面临的风险主要为移动终端面临的风险，包括App反编译、App二次打包、组件导出、WebView漏洞、键盘安全、屏幕截屏、数据安全、界面劫持、数据备份、Debug调试等。移动终端操作系统的漏洞缺陷众多，导致安卓(Andriod)、IOS等主流操作系统会经常更新，而移动App一般无法及时修改更新，经常出现安全漏洞。同时，移动终端属于个人并且联网，在浏览网页下载应用的过程中可能不知不觉就安装了盗版应用或者钓鱼应用，被插入了各种广告甚至病毒木马，这些软件都是在后台不知不觉中进行数据信息的窃取窃听，用户毫不知情，数据就可能已经被人获取分析利用了。这些App也可能成为攻击者的跳板，通过App的漏洞攻击后台服务器(图2)。

2.2 通信过程安全风险

通信过程面临的安全风险主要为智能手机客户端与服务器端交互所面临的风险，包括数据安全性缺乏保密性、中间人攻击、数据包可被篡改及重放等。一般使用手机App应用时用户习惯设置自动登录，这样一旦手机被他人使用或者丢失等情况发生时，就有可能造成数据或机密信息泄露。目前虽然很多App使用了https通信方式，但是只是对通信信道进行了加密，虽然可以防止监听数据的风险，但是没有对SSL证书的有效性做验证，无法防止中间人拦截代理方式，通过中间人攻击劫持，可以让采用https通信的数据暴露无遗，从而轻易获取手机用户的明文通信信息。

2.3 服务端安全风险

服务端安全风险主要来自传统业务系统架构面临的安全风险，主要有来自Web层面安全风险、数据库层面安全风险、安全策略风险、系统层安全风险等。无论是移动互联网系统还是传统业务系统，大多采用Web方式向客户端提供服务，Web应用安全漏洞层出不穷，例如XSS跨站脚本攻击漏洞、SQL Inject注入漏洞、恶意代码上传漏洞、Cookie注入漏洞等。大部分移动应用系统往往架设在Linux或者Windows操作系统上，采用WebSphere、Tomcat、Apache等中间件和Oracle、SQL Server等数据库，赖以运转的基础软件可能不时爆出一些系统漏洞，而每个漏洞都可能被攻击者所利用，造成账号失窃或数据篡改、数据泄露等。同时，应用设置的安全策略以及服务器设置的安全策略的不合适，都有可能造成安全风险(表1)。

表1 安全风险分析Tab.1 Security risk analysis

3 移动校园App防护对策

针对移动校园App的潜在风险分析，在“客户端、通信过程、服务端”3个方面提出一些移动校园App在建设过程中建议的安全防护对策。

3.1 客户端防护

部分检查方法：可以先利用反编译工具和二次打包工具对App进行反编译和二次打包，查看是否成功。采用工具检测组件是否存在导出风险。检查addJavascriptInterface接口、searchBoxJavaBridge_对象等，检查是否存在WebView漏洞。通过观察App在输入密码的地方是否会弹出自定义的软键盘。通过连续截图，查看是否可以捕捉到密码输入框的密码。查看AndroidManifest.xml文件中是否有allowBackup，如果没有则allowBackup属性值，默认allowBackup值为True，则默认为可以备份应用数据，存在安全风险。

建议修复方法：采用加密和混淆技术达到反编译保护。获取二次打包后APK的签名与正确的APK签名做对比，判断APK程序是否进行过二次打包。开发自定义软键盘而不是使用系统软件盘以防止键盘劫持。建议客户端针对第三方或系统截屏编写抵抗逻辑。删除不必要的接口和对象。把AndroidManifest.xml文件中allowBackup属性值设置为false。

软件防护的攻与防一直都不对等的，攻击者只需要找到薄弱的点即可，而防御者则需要做全面的防护，尽量做到不存在防御短板。加上Android App开源特性，以及各种成熟的反编译工具，即使软件开发人员对App进行了混淆和加密，还是会被逆向出代码逻辑和跳转，有了这些信息即使因为混淆代码无法拿到完整的源代码，但还是可以被黑客破解实现攻击诉求。目前市面上较成熟的客户端防护方案为通过代码加壳来实现对App源代码高强度的保护。App加壳技术经历了多次技术迭代，从最早的静态加密壳，到后来的动态保护壳，目前最先进且脱壳难度最高的是虚拟化执行壳。

3.2 通信过程防护

部分检查方法：通过抓包工具(例如burpsuite、fiddler)抓取通信信息，看是否进行加密通信。通过抓包看手机端程序是否运行正常，如果通过代理方式抓包，手机App自动强制退出，说明手机App有做证书校验。测试客户端访问的URL是否仅能由手机客户端访问，利用截包工具获取URL，能用浏览器打开该URL。

建议修复方法：使用https进行加密通信。采用证书强校验或弱校验，强校验就是在手机端先预埋好服务端的证书，当手机端与服务端通信时获取证书，并且与手机本地预埋的服务端证书做对比，一旦不一致，则认为遭到了中间人劫持攻击，自动断开与服务端的通信；弱校验则是在手机端校验证书的域名和手机真实访问的域名是否一致、证书颁发机构等信息。建议服务器进行相应的访问控制，控制对应页面仅能通过手机客户端访问。同时进行页面访问控制，防止绕过登陆直接访问页面的非法访问。

3.3 服务端防护

部分检查方法：利用工具或人工，对 Web 应用进行 SQL 注入、跨站脚本、上传漏洞、数据库泄露、弱口令、网页挂马等各种已知漏洞进行检测和验证。审查主机安全，查看审计日志等。查看应用是否设置正确的安全策略，如：是否可以设置弱密码、验证码是否检测使用次数、会话超时时间设置是否合理、安全退出机制是否合理等。

建议修复方法：对存在的Web漏洞进行源代码的相应修复，针对主机及时打补丁，及时的调整WFA和IPS防护设备策略，应用程序设置相应的安全策略，如强制使用强密码、验证码一次有效、会话设置合理超时时间、用户退出后及时清除服务器上的session等。

4 应用实践

对福建医科大学使用的移动校园App进行了检测，发现存在2个高危漏洞和多个中低危漏洞。高危漏洞为：程序反编译和WebView不校验HTTPS证书。

4.1 程序反编译漏洞

通过工具从安装包中抽取获取客户端XML配置文件，对XML配置文件进行预处理，扫描XML结构，形成标签-属性关系图。基于标签-属性关系图，进行上下文关联分析，获得相关对象属性值。进行语义分析，利用对象属性值结合上下文，依据相关特征，识别不安全的配置，发现存在可被反编译风险。具体分析如下：

4.2 WebView不校验HTTPS证书漏洞

通过破壳、逆向分析等获取移动校园App程序的Java源文件。对构成源程序的字符流进行扫描，通过词法分析，生成相关符号列表。进行语法分析，整理成语法树，通过抽象语法树分析，将程序组织成树形结构，构造Java类和函数库。进行语义分析，生成函数调用关系图，依据漏洞特征，遍历Java类和函数库，发现存在WebView不校验HTTPS证书的可能，具体表现为在证书认证错误时，绕过错误。

4.3 其他中危漏洞

通过分析，还发现移动校园App中还存在客户端、通信过程和服务端3个方面的不同中危漏洞，如：WebView密码明文保存、WebView远程调试、本地数据存储安全、服务端证书校验等。

建议修复对策：可以在使用WebView时设置webView.getSettings().setSavePassword(false)来关闭WebView的自动保存密码功能，防止用户密码被WebView明文存储；通过设置setWebContentsDebuggingEnabled为false来关闭WebView远程调试；应将敏感信息进行加密后存储，不要将密码等敏感信息存储在Shared Preferences等内部存储中；在客户端对服务器端证书校验的checkServerTrusted方法中对证书进行校验等。

通过上述分析检测以及修复整改，从而提升了该移动校园App整体安全性，降低广大师生受威胁的风险。

5 结语

随着智能终端应用越来越便捷，移动校园App也得到快速发展，一方面能够为广大师生提供最基本的校园信息服务，另一方面朝着功能更加丰富的移动办公学习平台发展[5]。越来越多的高校已经意识到移动校园App的重要性，本文通过分析移动校园App的潜在安全风险，研究检测方法，提出安全加固的对策，能较好地提升移动校园App整体的安全防范能力，对其他高校移动校园App的建设具有一定的参考借鉴价值。